We were also expecting to want to bound how much traffic a server could be
compelled to skip over without making progress. It actually didn't occur to
me we could let the client know the bounds, rather than just making up a
conservative bound (there's only so much data you can get into an RTT) and
On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara
wrote:
On Sat, Oct 08, 2016 at 01:03:21AM +, Nick Sullivan wrote:
> There has been a lot of discussion lately about post-handshake messages
> that do not contain application data and how to handle them. This PR is an
> attempt to make the story m
duce the complexity of
TLS 1.3 implementations that don't need these features.
Nick
On Sat, Oct 8, 2016 at 8:06 AM David Benjamin wrote:
On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara
wrote:
On Sat, Oct 08, 2016 at 01:03:21AM +, Nick Sullivan wrote:
> There has been a lot of discussio
To add to that, in out-of-order transports, whether a message was sent over
0-RTT or not may not even be very well-defined. If QUIC originally sent
data over 0-RTT but had to retransmit it after the full connection
parameters are available, I believe it will use those.
Even in an in-order transpor
Even without the Finished computation, rejecting a CertificateRequest would
hit the same unboundedness problem the previous generation of KeyUpdate had.
Our implementation currently treats all post-handshake CertificateRequests
as a fatal error. I think the only context where we'd conceivably chan
My interpretation was:
1. Client and server remember the previous selected ALPN protocol in the
session.
2. The client may offer whatever ALPN protocols it likes. It does not need
to match the previous offer list, though it presumably will unless you've
got a persistent session cache or so.
3. T
#x27;s configuration changed.) But after that, all your
new tickets are at h3 and the steady state is 0-RTT-capable again.
David
>
>
> Kyle
>
>
>
> *From:* Eric Rescorla [mailto:e...@rtfm.com]
>
>
> *Sent:* Wednesday, October 12, 2016 4:03 PM
>
> *To:* David
Sounds reasonable.
One concern is the F5 bug's failure mode was a timeout rather than an
error, so, if you take away padding, the allowance in C.3 will not save
heterogenous deployments where some servers do 1.3 and some are old F5
servers. But given we're talking about a straight-up server bug no
On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx wrote:
On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
> On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara
> wrote:
>
> > On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote:
> > > A few supp
On Mon, Nov 7, 2016 at 6:50 PM Benjamin Kaduk wrote:
(was Re: [TLS] PR#625: Change alert requirements)
Digging up an old sub-thread...
On 09/20/2016 08:03 AM, Eric Rescorla wrote:
in Record Layer there's the following text:
legacy_record_version : This value MUST be set to { 3, 1 } for al
I already hummed in the room, but I think it should stay as TLS 1.3. Either
of TLS 2 or TLS 4 makes the SSL/TLS silliness worse. One matches SSL 2.0
and the other just makes all this weirder. (Do we really want 2.0 < 3.0 <
1.0 < 1.1 < 1.2 < 4?)
TLS 1.3 is the natural next number and doesn't make a
On Tue, Nov 22, 2016 at 2:05 PM Olivier Levillain <
olivier.levill...@ssi.gouv.fr> wrote:
> Hi list,
>
> I am sorry for the very late answer concerning draft 18, but we
> (ANSSI) have several remarks after proof-reading the current
> specification.
>
> We are sorry for the multiple long messages.
On Thu, Dec 1, 2016 at 10:12 PM Peter Gutmann
wrote:
> Tony Arcieri writes:
>
> >There's already ample material out there (papers, presentations, mailing
> list
> >discussions, etc) which talks about "TLS 1.3".
>
> In other words, the TLS WG and a small number of people who interact with
> it
>
eers,
>
> Andrei
>
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Peter Gutmann
> Sent: Friday, December 2, 2016 12:33 AM
> To: Stephen Farrell ; David Benjamin <
> david...@chromium.org>; Tony Arcieri ; <
> tls@ietf.org>
&
On Mon, Dec 12, 2016 at 8:45 PM Martin Thomson
wrote:
> On 13 December 2016 at 12:43, Nick Harper wrote:
> > Right now, I believe it's legal for a client to send ClientHello, early
> > data, and end_of_early_data alert without reading any messages from the
> > server. This change would require a
Our implementation considers all post-handshake CertificateRequests to be a
fatal error to avoid this. We would do the same even with this proposal;
it's an unnecessary complexity (which translates to security risk). If the
protocol is such that the client will always bulk-disavow a burst of
unexpe
It's possible I'm misunderstanding your message here (I'm a little confused
by the mention of combining normal certificate authentication with an
external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH. That's
the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled by the
server
On Tue, Dec 27, 2016 at 4:44 PM Joseph Birr-Pixton
wrote:
Hi folks,
It appears to me that HRR is a pretty large and tricky source of
complexity in TLS1.3. Judging by the implementations page, 40% don't
support it right now. It's *precisely the kind of thing* that vendors
could easily ship broken
Done. Let me know if I did any of that incorrectly.
(Sorry about the delay. I've been some combination of suffering from a
cold, on vacation, or at conferences for the past month---usually more than
one at a time!)
On Tue, Jan 3, 2017 at 8:59 AM Sean Turner wrote:
I appears that we’ve got enoug
So, having uploaded draft-ietf-tls-grease-00, I would now like to rewrite
large chunks of it. The draft is currently defined for TLS 1.2, but it
probably makes sense to order it after TLS 1.3.
TLS 1.3 also adds a many new extension points, and we can expect new TLS
1.3 implementations popping up i
On Wed, Jan 18, 2017 at 8:15 PM Martin Thomson
wrote:
On 19 January 2017 at 14:04, Kazu Yamamoto wrote:
> Should we also add grease values for key_share?
supported_groups code points should cover that, but if you are asking
if we should spend bytes on sending shares for bogus groups, that's a
q
On Mon, Jan 30, 2017 at 4:45 PM Adam Langley wrote:
On Mon, Jan 30, 2017 at 1:41 PM, Scott Fluhrer (sfluhrer)
wrote:
> My question: in TLS 1.3, if the client inserts an extension of a type that
> the server does not recognize, how must the server behave? Is it required
> that the server just ig
I think this is much clearer, except for one bullet point below:
On Thu, Feb 2, 2017 at 10:22 AM Russ Housley wrote:
> [...]
> - If PSK and (EC)DH are being used together, then the server will:
>
> -- sends a "pre_shared_key" extension to indicate the selected
> key;
>
> -
NewSessionTicket always includes in-handshake client auth. The resumption
secret can't even be derived without it.
On Tue, Feb 14, 2017 at 10:21 AM David Wong
wrote:
> I can see this problem even in the case where the client sends an empty
> Certificate message during the handshake. If the appli
On Wed, Feb 15, 2017 at 2:49 PM David Wong
wrote:
> On Feb 15 2017, at 7:27 pm, Andrei Popov
> wrote:
>
> Yes, I agree that it is useful to mention this in the spec.
>
>
>
>
> It would be nice is to have two different PRs solving this issue. One
> mentioning this as a potential issue that the ap
This is a minor comment and purely aesthetic thing. Apologies for the
lateness in noticing. Hopefully it's not too late:
In TLS 1.3, we dropped the "ecdh_" prefix on ecdh_x25519 and ecdh_x448 when
we split signatures from NamedCurve/Group. The documents should probably
match in naming one way or a
Looks like TLS 1.3 already allows this for CT, though not OCSP. Would take
all of four characters to fix. See this table:
https://tlswg.github.io/tls13-spec/#rfc.section.4.2
One of the nice things about using TLS-style extensions in
CertificateRequest is any ClientHello => (Server)Certificate exte
smaller value in the
ticket to compensate for this difference.
David
On Mon, Mar 6, 2017 at 1:06 AM Martin Thomson
wrote:
> (Adding Filippo, who wrote the original change.)
>
> I just did some spelunking of the archives, and poking at boring SSL.
> I found that David Benjamin mentions
On Mon, Mar 6, 2017 at 5:52 PM Martin Thomson
wrote:
> On 7 March 2017 at 08:43, David Benjamin wrote:
> > To clarify, our interpretation of the spec was that it is the encrypted
> > data, not unencrypted data.
>
> Well, clearly we disagree. To be clear, I don&#x
On Tue, Mar 7, 2017 at 12:49 PM Eric Rescorla wrote:
> On Tue, Mar 7, 2017 at 9:44 AM, Roelof Du Toit > wrote:
>
> All,
>
>
>
> The current language in
> https://tlswg.github.io/tls13-spec/#rfc.section.4.1.4 states:
>
> As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions
> t
On Sun, Mar 12, 2017 at 8:09 PM Martin Thomson
wrote:
> On 13 March 2017 at 10:55, Brian Smith wrote:
> >> So, I'd prefer to bring session IDs back, and
> >> to arrange things so that they're always server-generated.
> >
> > Even in earlier versions, session IDs were not required with
> > resump
If there's to be a respin anyway, I have another small editorial comment:
https://github.com/tlswg/rfc4492bis/issues/36
On Wed, Mar 15, 2017 at 11:22 AM Eric Rescorla wrote:
> FWIW, there's a lot here, but I think it's all essentially editorial, so
> it shouldn't
> be that hard to clean up.
>
>
How's this look? https://github.com/tlswg/rfc4492bis/pull/37
On Wed, Mar 15, 2017 at 2:45 PM Yoav Nir wrote:
> There is (going to be a re-spin). There already is a PR there.
>
> If you can make a PR to solve your issue, that would be great.
>
> On 15 Mar 2017, at 19:20, D
draft-ietf-tls-rfc4492bis-15, section 5.11, contains the following text:
Since there are some implementation of the X25519 function that
impose this restriction on their input and others that don't,
implementations of X25519 in TLS SHOULD reject public keys when the
high-order bit of t
printing concern doesn't seem
> that serious in any case.
>
> -Ekr
>
>
> On Wed, Mar 15, 2017 at 1:25 PM, David Benjamin
> wrote:
>
> draft-ietf-tls-rfc4492bis-15, section 5.11, contains the following text:
>
>Since there are some implementation of the X25519
I think it's a typo. My understanding is EndOfEarlyData was meant to be in
the transcript.
David
On Fri, Mar 24, 2017 at 9:27 AM Matt Caswell wrote:
> In draft-19 EndOfEarlyData was changed from an alert to a handshake
> message. Therefore I would have expected to see it included in the
> calcu
On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk wrote:
> On 04/05/2017 09:21 AM, Eric Rescorla wrote:
>
> On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi
> wrote:
>
> Does cached-info not represent a privacy info-leak by disclosing past
> sessions prior to authenticating the new session? Versus compr
This seems overly complicated. Why implement a parallel key share mechanism
rather than merely defining a new NamedGroup value?
Using your example of Google's recent New Hope experiment, I would imagine
defining, say, NamedGroup.cecpq1. Let its key_shares be the concatenation
of New Hope and X2551
I too am in favor and willing to review it.
On Tue, May 16, 2017 at 9:25 AM Salz, Rich wrote:
> In favor, will review.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_
Seeing as this utterly ridiculous ticket_age_add thing is partially my
fault, I suppose I should respond:
On Fri, May 19, 2017 at 4:10 PM Colm MacCárthaigh
wrote:
> > And then separate to all of the above, and lower priority:
>> >
>> > * There's a contradiction between the obfuscated ticket age
On Tue, May 23, 2017 at 1:34 PM Benjamin Kaduk wrote:
> My initial thoughts...
>
>
> On 05/23/2017 06:50 AM, Markulf Kohlweiss wrote:
>
> I am paraphrasing a long thread on the issue that we had within
> the miTLS development team, and I am primarily commenting on the
> analysis aspects. I also h
On Wed, Jun 7, 2017 at 4:29 PM Ilari Liusvaara
wrote:
> On Wed, Jun 07, 2017 at 05:38:59AM +, Raja ashok wrote:
> > Hi Victor & Alessandro,
> >
> > I have gone through the draft and I am having a doubt.
> >
> > > The extension only affects the Certificate message from the server.
> > > It
On Wed, Jun 14, 2017 at 2:17 AM Petr Špaček wrote:
>
>
> On 13.6.2017 22:55, Ilari Liusvaara wrote:
> > On Tue, Jun 13, 2017 at 06:57:05PM +, Andrei Popov wrote:
> >> Regarding RFC language, I think we could be more specific:
> >>
> >>
> >>
> >> 1. A TLS implementation SHOULD/MUST only send 0
On Wed, Jun 14, 2017 at 5:01 PM Andrei Popov
wrote:
>
>- What if the server receives data with the 0-RTT boundary spanning an
>HTTP/2 frame? Is that a 0-RTT request? 1-RTT? Invalid?
>
> It appears safe to treat such data as 0-RTT; only the application can make
> this call, and it needs in
On Wed, Jun 14, 2017 at 6:47 PM Colm MacCárthaigh wrote:
> On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin
> wrote:
>
>> That is, it is not the identity of the bytes that matters much. It's
>> whether the connection has been confirmed when you perform an unsafe
>&
On Wed, Jun 14, 2017 at 7:31 PM David Benjamin
wrote:
> On Wed, Jun 14, 2017 at 6:47 PM Colm MacCárthaigh
> wrote:
>
>> On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin
>> wrote:
>>
>>> That is, it is not the identity of the bytes that matters much. It&#
0x is just the syntax for the maximum value in the enum.
The intent was to match the HashAlgorithm registry which makes 0xFE and
0xFF the private use values, so I would say the enum is correct and the
IANA considerations text is wrong. This ensures we don't collide with any
existing TLS 1.2 pr
> -Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> On Jul 5, 2017, at 1:22 PM, David Benjamin wrote:
>
> 0x is just the syntax for the maximum value in the enum.
>
> The intent was to match the HashAlgorithm regis
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,
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
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
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
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
[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
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
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
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
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
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
(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
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
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
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
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
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
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
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:
> 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
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
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
>
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
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
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
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
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
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
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
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.
>
>
>
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
401 - 479 of 479 matches
Mail list logo
