On Fri, Oct 4, 2024 at 11:32 AM Paul Wouters
wrote:
>
>
> On Fri, Oct 4, 2024 at 10:06 AM Ben Schwartz wrote:
>>
>> I've updated PR#16 to reframe this paragraph as a statement of fact:
>> https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16/files
>
>
> Speaking as individual,
>
>>
>>
>> It s
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 server instances S1, S2
> where T1 is served by both S1 and S2 but T2 only by
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:
>
> (Resending since I don't see these two mails in the list archives, so I'm not
> sure if the list software broke
To the extent it matters I support allocation so we can roll things
out and publish. TLS flags in particular has a lot depending on it.
--
Astra mortemque praestare gradatim
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le.
On Sun, Sep 8, 2024, 9:41 AM John Mattsson wrote:
> Hi,
>
>
> D. J. Bernstein wrote:
>
> > recent breaks of "5G Subscription Concealed Identifiers"
>
>
>
> The paper broke a hobby implementation of 5G which in addition to
> ignoring the mandatory point validation also ignored the mandatory point
decade
later and we still haven't been able to move past it. And just to make
explicit: this working group decided to ask CFRG to do something that
wasn't going to go well, and the results were worse than anticipated.
Unless we acknowledge that we're not going to be able to come up wi
I agree there have been a lot of electrons spilled. However despite
that there's a lot of questions about this negotiation mechanism's
impacts on browsers with lesser market share, site behavior, CA
support, command line utilities (a nightmare) that haven't really been
discussed and really deserves
On Tue, Jul 23, 2024, 11:04 AM Salz, Rich
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 not break any existing API.
>
> I think I agree with you, or at least as far as saying th
On Fri, Jul 19, 2024, 8:58 PM Salz, Rich
wrote:
>
> I've read it before. I the main issue is that it says "trusted" a lot.
>
>
>
> Yeah, kinda snippy but not necessarily wrong.
>
>
>
> I’m a little skeptical of approaches that solve an entire problem space with
> one architecture. I’m more skepti
I have read the document and think it is ready, minus the issues Rich
and Raghu identified.
On Fri, Jun 21, 2024 at 9:27 AM Sean Turner wrote:
>
> Gentle reminder this WGLC is still ongoing.
>
> spt
>
> > On Jun 12, 2024, at 14:10, Sean Turner wrote:
> >
> > This email starts the working group l
On Wed, Jun 5, 2024 at 6:24 AM Peter Gutmann wrote:
>
> Martin Thomson writes:
>
> >Are you saying that there are TLS 1.3 implementations out there that don't
> >send HRR when they should?
>
> There are embedded TLS 1.3 implementations [*] that, presumably for space/
> complexity reasons and poss
On Wed, Jun 5, 2024 at 8:38 AM Andrei Popov
wrote:
>
> This is my understanding too, and I believe a lot of deployments limited to
> P384 will want to use a P384-based hybrid, at least “in transition”. The
> duration of this transition could be years…
I really do not understand this argument, g
in case (3) we'd send L1, M1, M1' where M1' is signed by the root
N1, and M1 by some PQ root. In case (2) I'm not sure how this would
work: the end entity cert must be first, but you're requiring two
different ones (with the same key), and I don't know a way to fi
er the
argument for inclusion. I don't see how Trust Expressions isn't making
this scenario easier.
Furthermore the decision to add a CA is multifacited and balances the
utility to subscribers against the security costs. I am on the record
as an advocate for aggressively swinging towards quantifying the
utility here: no one is entitled to get trusted just because they can
comply with the CA/B forum rules. The number of certs issued (and
hence servers covered) is part of the utility calculation.
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
On Thu, May 23, 2024 at 12:42 PM David Benjamin wrote:
>
> Of course, whether this property (whether servers can usefully pre-deploy
> not-yet-added trust anchors), which trust expressions does not have, even
> matters boils to whether a root program would misinterpret availability in
> server
On Tue, May 21, 2024 at 4:56 PM David Benjamin
wrote:
>
> 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
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 wrote:
>>
>> I hope, as the WG are processing this
>> [draft-davidben-tls-key-share-prediction], we consider
ent signer. So Country X could force its sites to include
that cross-signed intermediate in the grab bag handed to browsers, and
everything would work as now. Browsers have to tolerate all sorts of
slop there anyway. I think the sharper concern is that you could block
traffic without the cert inclu
On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla wrote:
>
>
> On the narrow point of shorter lifetimes, I don't think the right way to
> advertise that you have an accurate clock is to advertise that you support
> some set of root certificates.
>
> If we want to say that, we should have an extensio
On Sat, Apr 27, 2024, 8:03 AM David Benjamin wrote:
> What should the next steps be here? Is this a bunch of errata, or
> something else?
>
Errata at a minimum but this might be big enough for a small RFC describing
the fix.
>
> On Wed, Apr 17, 2024 at 10:08 AM David Benjamin
> wrote:
>
>> > S
On Tue, Apr 23, 2024 at 1:39 PM Devon O'Brien
wrote:
>
> After sharing our first draft of TLS Trust Expressions and several
> discussions across a couple IETFs, we’d like to proceed with a call for
> working group adoption of this draft. We are currently prototyping trust
> expressions in Bori
On Tue, Apr 2, 2024, 5:08 PM Eric Rescorla wrote:
> Adoption should not be required to register a code point [0], as the
> policy is Specification Required.
>
> I'm mildly negative on adopting this document. What is the reason we need
> to spend WG time on this, rather than just having a code poi
On Fri, Mar 15, 2024 at 2:23 PM Stephen Farrell
wrote:
>
>
> Hiya,
>
> I think the outcome here is maybe most likely to do nothing but
> since the WGLC is ongoing I figured it best to bring it up in
> case others have better ideas.
>
> I got a mail yesterday from someone who had played with the ng
On Wed, Mar 13, 2024 at 6:39 PM Deirdre Connolly
wrote:
>
> Some considerations for ML-KEM alone (or another trusted PQ-only key
> agreement) are mainly looking towards the desired next step after hybrid key
> agreement, and instead of leaving that fuzzy and far off, talking about it in
> the p
if I am missing something obvious, but as someone
> who used ESNI successfully back when it was in draft status, and was
> happy with no SNI being leaked, I am unhappy that it has returned.
DNS does not propagate atomically with webserver configuration
changes. It's thus necessary to deal with mismatches.
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
LGTM
On Tue, Mar 12, 2024 at 7:58 AM Sean Turner wrote:
>
> This is the working group last call for the SSLKEYLOGFILE Format for TLS
> Internet-Draft [1]. Please indicate if you think the I-D is ready to progress
> to the IESG and send any comments to the list by 31 March 2024.
>
> The GH repo
On Mon, Mar 11, 2024 at 3:00 PM Joseph Salowey wrote:
>
> This is the working group last call for TLS Encrypted Client Hello [1].
Please indicate if you think the draft is ready to progress to the IESG and
send any comments to the list by 31 March 2024. The comments sent by
Watson Ladd
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 algorithm, I thought it
> would be a good time to remind folks that, right now, we have no way to
On Wed, Mar 6, 2024, 10:48 AM Rob Sayre wrote:
>
> On Wed, Mar 6, 2024 at 9:22 AM Eric Rescorla wrote:
>>
>>
>>
>> On Wed, Mar 6, 2024 at 8:49 AM Deirdre Connolly
>> wrote:
>>>
>>> > Can you say what the motivation is for being "fully post-quantum" rather
>>> > than hybrid?
>>>
>>> Sure: in th
something no one will be
able to get interoperability.
For a very complex protocol that's taken quite some years to develop
this document is in pretty good shape.
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Wed, Jan 10, 2024 at 12:14 PM Bas Westerbaan
wrote:
>
> Dear tls and cfrg working groups,
>
> With ML-KEM (née Kyber) expected to be finalized this year, it’s time to
> revisit the question of which PQ/T hybrid KEMs to standardize, and which to
> recommend.
My preference would be that we use
On Wed, Dec 13, 2023 at 10:29 AM Christian Huitema wrote:
>
> Doing a PQ version of ECH would be hard. On the other hand, doing an
> 8773-like enhancement to ECH should not be all that hard. It would
> require that the outer CH contains a PSK shared between the client and
> the fronting server, a
On Tue, Dec 12, 2023 at 1:23 AM Peter Gutmann wrote:
>
> Viktor Dukhovni writes:
>
> >Peter, is there anything beyond TLS-TLS that you're looking to see work on?
> >Is the issue foreclosing on opportunities to do anticipated necessary work,
> >or is it mostly that the statement that the work can'
On Mon, Dec 11, 2023 at 5:15 PM Peter Gutmann wrote:
>
> In all the rush to jump on the bandwagon, no-one has yet answered the question
> I posed earlier: For anyone who's already moved to TLS 1.3 the draft is
> irrelevant, and for people who have to keep supporting TLS 1.2 gear more or
> less ind
On Tue, Dec 5, 2023, 9:34 PM 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 to confirm this on the list. Please indicate if y
or D, but
then does IESG Approval kick in as well? Conversely is IESG approval
the only way to make something N? I think the answer to this as
written is yes, while the first one is genuinely unclear.
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
_
On Tue, Nov 21, 2023 at 9:03 PM Sean Turner wrote:
>
> Hi! I sent over the early allocation request and the IANA folks rightly
> pointed out two things that need to be added. This email is to make sure we
> have agreement on the two changes to the registrations in s11.1. If you don’t
> agree wi
I wish we didn't need this draft, but I support adoption and can review it.
On Mon, Nov 6, 2023 at 9:25 AM 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
> (https://datatracker.ietf.org/doc/
On Mon, Nov 6, 2023, 10:07 AM Kris Kwiatkowski wrote:
> So, based on FIPS 140-3 I.G., section C.K., resolution 5, [1]. "SP800-186
> does not impact the curves permitted under SP 800-56Arev3. Curves that are
> included in SP 800-186 but not included in SP 800-56Arev3 are not approved
> for key agr
I'm most interested in Level I which I think is what the current
browser deployments have targeted. Higher security levels are much
less relevant at least for now, and I think the platforms will likely
look different.
I think ML-KEM-768 codepoint and a hybrid one make sense to grab now:
AFAIK it's
On Mon, Oct 23, 2023 at 9:52 AM Jonathan Hoyland
wrote:
>>
>> I'm not following how this identifies web crawlers, unless perhaps we're
>> using the term to mean different things? I would expect web crawlers to
>> typically not do much with client certificates, and to typically want to
>> index
ile in principle, but I wouldn't be surprised if the
analysis comes back "HTTP usages haven't changed enough" for a bit.
Sincerely,
Watson Ladd
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Wed, Jul 12, 2023, 11:31 AM Tim Hollebeek wrote:
> SCTs have always seemed surprisingly large to me, and it has always seemed
> like there should be a more compact representation that has the same
> security
> properties, but I've never found the time to look more closely at it. If
> someone
On Thu, May 11, 2023, 7:17 AM Kampanakis, Panos wrote:
> Great!
>
> So to clarify, when Kyber gets ratified as MLWE_KEM or something like
> that, will we still be using 0x6399 in the keyshare when we are
> negotiating? Or is 0x6399 just a temporary codepoint for Kyber768 Round 3
> combined with
On Sun, Mar 26, 2023, 7:03 PM Rob Sayre wrote:
>
>
> On Sun, Mar 26, 2023 at 6:51 PM Watson Ladd wrote:
>
>>
>>
>> On Sun, Mar 26, 2023, 5:05 PM Rob Sayre wrote:
>>
>>> Hi,
>>>
>>> The problem is also incompletely described, right
ll means explain it, but telling people that they have a "total lack
>> of kernel-side insight" or that their "technology and ideas will be
>> totally
>> left behind" doesn't really foster good will.
>>
>>
>> On Sat, Mar 25, 2023 at 12:41
er starting at 1
that occupies the low 32 bits to get the keystream.
Are you proposing just using AES-CTR ignoring the record segmentation entirely?
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
d the user-agent, not the site,
determines what transparency service is used. This makes it much more
difficult for sites to be sure their certificates will actually work.
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
___
TLS mailing list
TL
On Fri, Mar 3, 2023, 1:50 PM Viktor Dukhovni wrote:
>
> On Fri, Mar 03, 2023 at 08:17:55PM +0200, Nimrod Aviram wrote:
>
> > Specifically, we will have to decide when/if to deprecate version 1.2 of
> > TLS within, say, the next 20 years.
>
> 20 years is a long time. We can only reason about short
On Wed, Feb 8, 2023 at 10:16 AM Boris Pismenny
wrote:
>
> Hello,
>
> I work on NIC hardware acceleration for NVIDIA, and we are looking into
QUIC and DTLS1.3 acceleration. QUIC and DTLS employ packet number
encryption (PNE) which increases security. At the same time, PNE
significantly encumbers ha
On Fri, Jul 16, 2021 at 4:56 PM Christopher Wood wrote:
>
> This is the second working group last call for the "A Flags Extension for TLS
> 1.3" draft, available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
>
> Please review this document and send your comments to the l
-tls-sic>-sic
> <https://datatracker.ietf.org/doc/html/draft-thomson-tls-sic> which
> should be revived imo.
>
>
>
> Cert compression will not help as these big certs mostly consist of big
> keys or sigs which are random sequences and thus do not benefit from
> compression.
>
In some sense draft-thompson-tls-sic is compression with a dictionary of
known intermediates.
>
>
> Rgs,
>
> Panos
>
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
I support adoption. We've seen interest in adding PAKE to TLS several
times, including in RFC 5054, recent drafts, etc. Having the selected
PAKE from the CFRG in TLS is important.
On Tue, Mar 30, 2021 at 9:39 PM Joseph Salowey wrote:
>
> Hi Folks,
>
> We had a presentation on TLS opaque at IETF 1
ink this is less relevant.
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Wed, Mar 10, 2021 at 11:25 AM Robbie Harwood wrote:
>
> Hello kitten and TLS,
>
> Our document defining TLS 1.3 channel bindings is now in 2-week last
> call (to end 2021-03-24). That document can be viewed at:
>
> https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls
legitimate owner.
Only if the protocol has the security properties you want. That's not
clear to me, and the Wifi Alliance should have something to back this
up.
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
y as strong as "MUST NOT", which is what I take
> deprecation to mean. Am I wrong about the intended meaning of
> "deprecation"?
There is no protocol police. To the extent that industries want to
ensure that systems are secure, they have to ensure updates for the
life o
if the TLS handshake analysis shows
that the handshake is secure if the underlying exchange is secure,
it's not clear the underlying handshake is secure.
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
___
TLS mailing list
TLS@ietf.org
https
what property you want here that is stronger.
Sincerely,
Watson Ladd
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Fri, Jan 29, 2021 at 7:52 AM John Mattsson
wrote:
>
> Hi,
>
> 3GPP has historically to a large degree used IPsec to protect interfaces in
> the core and radio access networks. Recently, 3GPP has more and more been
> specifying use of (D)TLS to replace or complement IPsec. Most 3GPP usage of
Dear all,
After reading all 50 odd emails I'm perpetually confused as to what is
going on, each email and the doc confusing me further. It seems that
similar to QUIC there is an attempt to put TLS over a non TCP
transport and then use for signaling user authentication via X509
certificates, and th
#x27;re free to continue ignoring the RFC series. But
reality does not go away if it is ignored.
Sincerely,
Watson Ladd
>
> Thanks
>
> Mike
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Dear TLS WG,
I think RFC 7627 should update 5056, 5705, and maybe a few more.
I noticed these omissions when looking at the kitten draft to use TLS
1.3 exporters. Having these updates would hopefully make clear what
uses need to be updated, or at least show where there might be a
problem.
Sincer
On Sat, Oct 10, 2020 at 11:27 PM Achim Kraus wrote:
>
> Hi Joe,
>
> > [Joe] It's unfortunate to find issues that require breaking change at
> > the end of the review cycle, especially for a draft that has taken a
> > long path to get here. If there is an issue that is exploitable, even
> >
also suspect
> but I haven't worried about those yet. My original
> message below explains which primes I'm talking about.
POC || GTFO
Sincerely,
Watson Ladd
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
isn't possible in X509 due to
inordinate flexibility is one of many pitfalls for implementors. This
sort of issue periodically leads to authentication bypasses and other
such fun.
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
formance processors where crypto is lightning fast.
> But don't forget the other family of processors, of which there are probably
> more than a 80 billion out in the wild already.
>
> Ciao
> Hannes
>
> -Original Message-
> From: TLS On Behalf Of Watson Ladd
&g
On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL
wrote:
>
> I share Achim's concerns.
>
> But I believe the explanations will turn out mostly useless in the real
> world, as the "lawyers" of the industry are guaranteed to steer away from
> something "not recommended".
>
> In one w
On Mon, Sep 28, 2020 at 6:33 PM Michael D'Errico wrote:
>
> On Mon, Sep 28, 2020, at 11:07, Hannes Tschofenig wrote:
> >
> > Luckily, we don't have any angry cryptographers in this group.
>
> Were they all pushed away too?
>
> Anyway, back on the topic of stateless HelloRetryRequest, I
> don't see
ds a certain special handling. Indeed
> that’s a form of fingerprinting (greases field XYZ).
The whole point of grease is keeping extensions open. Coding special
handling defeats the purpose.
Sincerely,
Watson Ladd
>
> Eliot
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Wed, Jul 29, 2020, 7:51 PM Yiannis Yiakoumis
wrote:
> Hi Ben,
>
> Thanks for your comments. Please find some responses inline.
>
> On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz wrote:
>
>> This proposal is highly ossifying. Application protocols that are
>> included in this scheme become ver
On Mon, Jul 27, 2020, 1:15 AM Eric Wang (ejwang) wrote:
> Hi Stephen,
>
> Thanks for your feedback. I’d like to clarify, given the reality today
> that CDN/load balancers and enterprises deploy TLS proxy, this draft is
> merely to lay out a baseline guidance to the implementation and
> operation
On Tue, Jul 14, 2020 at 3:38 PM Salz, Rich
wrote:
>
> I would love to see a sample cert and private key in “PEM format” and samples
> of the TLS extensions encoded, or even a simplified handshake dump.
https://github.com/tlswg/tls-subcerts/pull/77
>
>
tion 7.1.1. While it's a good idea to compare byte by byte, humans
entering PSK identifiers may run into trouble due to all the ways
visually identical strings may not actually be identical. It might be
worth calling this out as a consideration.
Sincerely,
Watson Ladd
__
y
out X509 validation against a trust store or validation function and
treat the empty authenticator as invalid. That way someone has to
think before not checking the certificate returned.
Sincerely,
Watson Ladd
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Fri, May 29, 2020 at 5:01 PM David Benjamin wrote:
>
> Hi all,
>
>
> As we’ve been using TLS 1.3 in more scenarios, we’ve encountered some
> interesting interactions with TCP. We thought we’d document these and send a
> note here. In general, we've found that TLS implementations need to be wa
sitate.
Anyway it sounds like no one really has a problem with an extension,
just a question.
Sincerely,
Watson Ladd
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Sat, May 9, 2020 at 9:08 AM Salz, Rich
wrote:
>
> Sorry for the confusion I caused.
>
> HKDF is part of SP 800-56C. NIST says that what TLS 1.3 does isn't quite
the same, and therefore will not be covered by 56C. NIST wants to get TLS
1.3 validated for FIPS, and is currently trying to figure o
'ELLO
On Thu, May 7, 2020 at 7:03 PM Tommy Pauly
wrote:
>
> ECHO is more fun to say, but I do see how it can be confusing (sounding like
> some sort of ping) when out of the context of TLS.
>
> To that end, I’d have a minor preference for “ETCH”.
>
> Thanks,
> Tommy
>
> > On May 7, 2020, at 3:52
One thing I noticed from my reading is there is no gain from knowing
an extension will be present if one doesn't also know the value. I
could imagine SNI being very useful to include, and knowing the order
of extension values permits their omission, keeping only the length.
This does mean very litt
On Thu, Mar 5, 2020 at 3:08 PM Nico Williams wrote:
>
> On Thu, Mar 05, 2020 at 02:49:23PM -0800, Watson Ladd wrote:
> > On Thu, Mar 5, 2020 at 12:55 PM Nico Williams wrote:
> > > unless both parties agree. It takes two to agree.
> >
> > As far as I am a
On Thu, Mar 5, 2020 at 12:55 PM Nico Williams wrote:
>
> unless both parties agree. It takes two to agree.
As far as I am aware session tickets being single use isn't enforced
by any server right now: it's a desirable but theoretical property for
0-RTT.
My skepticism is entirely a function
On Wed, Mar 4, 2020 at 6:07 PM Stephen Farrell
wrote:
>
>
> Hiya,
>
> On 04/03/2020 16:06, Sean Turner wrote:
> > Must the ticket reuse use case be addresses
> > in draft-ietf-tls-ticketrequests?
>
> Yes. I think Viktor's use case is one to not bugger
> up (even if one doesn't need to support it
ate*. That's the whole
> point of IETF standards.
A failure to resume does not break the connection. Tickets may age out
anyway, or the server might have dropped state on restart, etc. So
there is no interoperability problem.
Sincerely,
Watson Ladd
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Wed, Mar 4, 2020 at 8:07 AM Sean Turner wrote:
>
> one more time ...
>
> All,
>
> The purpose of this message is to help the chairs judge consensus on the way
> forward for draft-ietf-tls-ticketrequests. The issue at hand is whether the
> client-initiated ticket request mechanism [0] should b
The PR looks good to me.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Fri, Feb 21, 2020 at 2:25 PM Stephen Farrell
wrote:
>
>
>
> On 21/02/2020 22:11, Watson Ladd wrote:
>
> > https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/
> > https://blog.cloudflare.com/the-tls-post-quantum-experiment/
> >
> &
On Fri, Feb 21, 2020 at 2:08 PM Stephen Farrell
wrote:
>
>
>
> On 21/02/2020 22:02, Watson Ladd wrote:
> > We have already deployed widespread experiments that conducted the
> > hybridization described in this draft, already have implementations
> > supporting an
ishes that we need to know that we do
not know today? Which algorithm we want to hybridize? That's easy to
handle: the mechanism is generic.
Sincerely,
Watson Ladd
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Wed, Feb 12, 2020 at 3:23 PM Martin Thomson wrote:
>
> On Thu, Feb 13, 2020, at 10:01, Carrick Bartle wrote:
> > I'm brand new to the IETF, so please forgive me if I'm totally off base
> > here, but my understanding is that Informational RFCs are explicitly
> > not recommendations (let alone ma
gt;
> - Much longer time window to perform the attack (limited by certificate
> lifetime, not how long client waits).
> - One can impersonate server multiple times per successful attack, not
> just once.
>
> This could be generalized
On Sat, Feb 1, 2020 at 7:59 PM Viktor Dukhovni
wrote:
> On Sat, Feb 01, 2020 at 07:04:53PM -0800, Watson Ladd wrote:
>
> > > The benefit of the new value of "0" is *unambiguous* signalling that
> the
> > > client would like to reuse the ticket if possible,
On Sat, Feb 1, 2020 at 5:30 PM Viktor Dukhovni
wrote:
> On Sat, Feb 01, 2020 at 07:53:57AM -0800, Tommy Pauly wrote:
>
> > Instead, it seems unclear what value the special use of 0 and 255 adds
> > that wouldn’t be better served by a separate extension.
>
> The benefit of the new value of "0" is
On Thu, Jan 23, 2020, 4:41 AM Viktor Dukhovni
wrote:
> On Thu, Jan 23, 2020 at 12:57:31PM +0100, Hubert Kario wrote:
>
> > > The deployed base of Postfix servers issues multi-use tickets (always,
> > > there's no extension to tell me otherwise), and sends zero tickets
> > > on resumption, so I ne
On Wed, Jan 22, 2020 at 4:56 PM Nico Williams wrote:
>
> On Tue, Jan 21, 2020 at 06:19:23PM +, Salz, Rich wrote:
> > Viktor and I spoke in more detail. The use-case he brings up makes
> > more sense to me now. The key observation is that this is not about a
>
> I also spoke to Viktor, and he
On Thu, Nov 21, 2019, 5:28 PM Sean Turner wrote:
> At IETF 106 there was support for adoption of "Semi-Static Diffie-Hellman
> Key Establishment" for TLS 1.3 [0] as a WG item. To confirm this on the
> list: if you believe that the TLS WG should not adopt this as a WG item,
> then please let the
On Wed, Oct 23, 2019 at 7:35 AM Bill Frantz wrote:
>
> A perhaps radical suggestion:
>
> Make the server name field fixed length e.g. 256 bytes. Longer
> server names are not supported and clients MUST NOT send them.
> (Both client and server can't use them because they won't fit in
> the fixed le
On Tue, Oct 22, 2019 at 7:54 PM Rob Sayre wrote:
>
>
>
> On Tue, Oct 22, 2019 at 7:29 PM Salz, Rich wrote:
>>
>>
>>
>> Low numbers might encounter all sorts of well-known cryptographic problems,
>> and varying the padding of the domain name with any granularity would tend
>> to narrow the searc
On Wed, Oct 16, 2019, 4:13 PM Martin Thomson wrote:
> On Tue, Oct 15, 2019, at 17:13, Nick Sullivan wrote:
> > One may note that no matter what the choice is with respect to RSA,
> > this particular wrinkle also applies more broadly. For example, if a
> > client advertises support for ed25519 in
On Thu, Oct 10, 2019, 8:54 AM Salz, Rich wrote:
>
>- I want to keep the SNI encrypted in TLS hops that use client
>certificates, but where ESNI won't work.
>
>
>
> I have some questions about this, see below.
>
>
>
>- For example, how is the SNI transmitted in the parens here:
>
>
>
>
1 - 100 of 295 matches
Mail list logo
