Document: draft-vvv-tls-cross-sni-resumption-00.txt
I think we should adopt this draft. Some review comments below.
S 1.
Section 4.2.11). However, in the absence of additional signals, it
discourages using a session ticket when the SNI value does not match
([RFC8446], Section 4.6.1), as
On Thu, Dec 3, 2020 at 11:12 AM David Benjamin
wrote:
> On Thu, Dec 3, 2020 at 1:16 PM Eric Rescorla wrote:
>
>>If a client certificate has been associated with the session, the
>>client MUST use the same policy on whether to present said
>>certificate to th
Hmmm... I think it probably goes in this draft, but I'm open to being wrong.
On Thu, Dec 3, 2020 at 12:46 PM Salz, Rich wrote:
>
>- I'm not sure if it's ever been written down anywhere (probably
>should be...), but I think resumption is pretty much universally
>interpreted as authen
On Sat, Dec 5, 2020 at 7:05 AM Yoav Nir wrote:
> Hi.
>
> At IETF 108 a question was raised about The TLS Flags extension. What
> payloads on the server side can include this extension?
>
> The “candidates” are ServerHello, EncryptedExtensions, Certificate, and
> NewSessionTicket.
>
> The only o
Ben,
Thanks for your review.
> I made a pull request with editorial/nit-level stuff at
> https://github.com/tlswg/dtls13-spec/pull/160 (though some editorial
> issues remain mentioned here where there is a lot of flexibility in how
> to resolve them).
I will take a look at these.
> I think th
On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok wrote:
> On Jan 3, 2021, at 10:44 PM, Martin Thomson wrote:
> > # Key Schedule
> >
> > The other thing I observe is the way that this slices up the exporter
> output. This was something that old versions of TLS did, but TLS 1.3 did
> away with. Though
On Tue, Jan 5, 2021 at 7:54 PM Benjamin Kaduk wrote:
> Changing Subject: and adding tls@ ...
>
> On Wed, Jan 06, 2021 at 02:04:02PM +1100, Martin Thomson wrote:
> > Hi Ben,
> >
> > I'm going to respond here to your DISCUSS points, but leave the comments
> to our issue tracker. Lucas has voluntee
On Thu, Jan 7, 2021 at 4:39 PM Benjamin Kaduk wrote:
> On Mon, Jan 04, 2021 at 03:40:34PM -0800, Martin Duke via Datatracker
> wrote:
> > Martin Duke has entered the following ballot position for
> > draft-ietf-tls-external-psk-importer-06: Discuss
> >
> > When responding, please keep the subject
On Fri, Jan 22, 2021 at 1:55 AM Nick Harper wrote:
> On Thu, Jan 21, 2021 at 9:46 PM Martin Thomson wrote:
>
>> In other words, each flag is treated just like an empty extension: you
>> can initiate an exchange with it, but you can only answer with it if it was
>> initiated with it.
>>
>> I agre
Good catch. I have filed https://github.com/tlswg/tls13-spec/issues/1208 to
address it.
-Ekr
On Fri, Jan 29, 2021 at 6:29 AM John Mattsson wrote:
> Hi,
>
> I think Section 6.1 Closure Alerts is a bit unclear:
>
> First it is stated the user_canceled SHOULD be followed by close_notify
>
>"T
On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok
wrote:
> This is a new message to summarize history, requirements, etc. for
> EAP-TLS and TLS 1.3. The focus here is the requirements for EAP-TLS, and
> how the 0x00 commitment message versus CloseNotify meets those. I'll
> ignore the exporter chang
On Mon, Feb 1, 2021 at 7:42 AM Alan DeKok wrote:
> On Feb 1, 2021, at 9:55 AM, Eric Rescorla wrote:
> > Let's take the second case first. If the server is sending (or
> > potentially sending) post-handshake messages after the client's second
> > flight (e.g.
On Mon, Feb 1, 2021 at 8:22 AM Alan DeKok wrote:
> On Feb 1, 2021, at 11:09 AM, Eric Rescorla wrote:
> > That's not what I'm proposing. I'm only talking about the case where the
> server says this after flight (2).
>
> OK, my misreading of the text.
>
On Thu, Feb 4, 2021 at 12:57 AM John Mattsson
wrote:
> Hi,
>
>
>
> I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS
> interact better is a very promising idea. This would probably take some
> time to get specified and implemented so it is probably a future
> optimization/simpli
On Thu, Feb 4, 2021 at 6:29 AM Eric Rescorla wrote:
>
>
> On Thu, Feb 4, 2021 at 12:57 AM John Mattsson
> wrote:
>
>> Hi,
>>
>>
>>
>> I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS
>> interact better is a very promising
On Fri, Feb 5, 2021 at 5:16 PM Benjamin Kaduk wrote:
> Hi Ekr,
>
> Thanks for all the updates, and sorry to have dropped the ball over the
> holidays.
>
> The changes in the -40 are basically all good, and I filed several PRs to
> cover a few nits and places where you asked for suggested text. (
I have posted -41, which I believe to be ready for IETF LC
-Ekr
On Sun, Feb 7, 2021 at 12:36 PM Eric Rescorla wrote:
>
>
> On Fri, Feb 5, 2021 at 5:16 PM Benjamin Kaduk wrote:
>
>> Hi Ekr,
>>
>> Thanks for all the updates, and sorry to have dropped the ball o
Agreed. With that said, I don't think it would hurt to add some text. John,
would you like to provide a PR?
-Ekr
On Wed, Feb 10, 2021 at 8:11 AM Salz, Rich wrote:
>
>- Previous versions of TLS explicitly offered a null cipher (wherein
>encryption consists of the identity operation, i.e
John,
Thanks for raising this topic I think it's important. I agree with you on
the technical situation. As you say, we should be encouraging people to
move to TLS 1.3, and NULL encryption cipher suites do not provide all the
guarantees that TLS 1.3 is intended to deliver. [0].
I also agree with
On Thu, Feb 11, 2021 at 11:13 AM Jack Visoky
wrote:
> Hi John, Eric,
>
>
>
> Thanks for the input. We will certainly make some changes to the draft
> regarding the inspection case. However, I can’t support removing the
> performance/latency information completely, as I have heard from those who
>
th to the hardware each time.
-Ekr
Note I am not endorsing this platform or affiliated with it in any way,
> just want to give an example. And it really is just an example, sorry to
> repeat again but I just want to drive home the point that YMMV on things
> like this.
>
>
>
> Tha
I am not in favor of shrinking this to a single byte, as it significantly
limits future flexibility.
As far as I can tell, the argument here is to limit the entropy available
for tracking, but recall that in this case the attacker controls the DNS
and they can (for instance) provide a unique IPv6
On Tue, Feb 16, 2021 at 3:01 PM Martin Thomson wrote:
> On Wed, Feb 17, 2021, at 08:31, Christopher Wood wrote:
> > That's true, but I'd personally prefer one tracking vector to two. This
> > structure also better aligns with other proposed use cases for HPKE
> > configurations. I also don't see
On Tue, Feb 16, 2021 at 4:21 PM Carrick Bartle
wrote:
> It's not significant extra complexity to have this field bigger and it
> basically makes it impossible to have any structure.
>
>
> What do you mean by structure? How does a byte not provide sufficient
> "structure"?
>
It's not long enough
On Tue, Feb 16, 2021 at 4:31 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 16/02/2021 21:31, Christopher Wood wrote:
> > That's true, but I'd personally prefer one tracking vector to two.
> > This structure also better aligns with other proposed use cases for
> > HPKE configurations. I also don't se
On Tue, Feb 16, 2021 at 4:44 PM Stephen Farrell
wrote:
>
>
> On 17/02/2021 00:34, Eric Rescorla wrote:
> > How is it any harder to manage a multi-octet server-chosen value than a
> > single-octet server-chosen value?
>
> Easier for the library on the server side. If i
On Wed, Feb 17, 2021 at 8:24 AM Stephen Farrell
wrote:
>
>
> On 17/02/2021 16:00, Eric Rescorla wrote:
> > On Tue, Feb 16, 2021 at 4:44 PM Stephen Farrell <
> stephen.farr...@cs.tcd.ie>
> > wrote:
> >
> >>
> >>
> >> On 17/02/2021 00:
On Fri, Mar 5, 2021 at 11:38 AM Watson Ladd wrote:
> On Fri, Mar 5, 2021, 10:43 AM John Mattsson
> wrote:
> >
> > >While renegotiation will never be re-added, there is post-handshake
> > >authentication (RFC 8446, section 4.6.2), and while that is currently
> > >about authenticating the _client_
Taking a step back from the crypto, I'm trying to make sure I
understand the desired security properties. As I understand the
situation:
- the client has a preconfigured key pair (X_c, Y_c)
- the server is anonymous (i.e., doesn't have a valid TLS cert).
- the server is preconfigured with informat
On Mon, Mar 8, 2021 at 1:18 PM Dan Harkins wrote:
>
> Hi Eric,
>
> On 3/8/21 8:00 AM, Eric Rescorla wrote:
>
> Taking a step back from the crypto, I'm trying to make sure I
> understand the desired security properties. As I understand the
> situation:
>
> -
On Tue, Mar 9, 2021 at 11:43 PM Owen Friel (ofriel)
wrote:
>
>
>
>
> *From:* TLS *On Behalf Of *Eric Rescorla
> *Sent:* 09 March 2021 06:27
> *To:* Dan Harkins
> *Cc:*
> *Subject:* Re: [TLS] Comments on draft-friel-tls-eap-dpp-01
>
>
>
>
>
>
&
On Wed, Mar 10, 2021 at 7:12 AM Dan Harkins wrote:
>
>
> On 3/10/21 4:12 AM, Eric Rescorla wrote:
>
>
>
> On Tue, Mar 9, 2021 at 11:43 PM Owen Friel (ofriel)
> wrote:
>
>> *From:* TLS *On Behalf Of *Eric Rescorla
>> *Sent:* 09 March 2021 06:27
>> *
I have filed https://github.com/tlswg/tls13-spec/issues/1225 for this point.
On Tue, Mar 16, 2021 at 12:00 PM Ben Schwartz wrote:
> RFC8446 (and bis) currently describe a "cache timing" attack on use of
> Early Data:
>
>* Exploiting cache timing behavior to discover the content of 0-RTT
>
On Wed, Mar 24, 2021 at 7:18 PM John Scudder via Datatracker <
nore...@ietf.org> wrote:
> John Scudder has entered the following ballot position for
> draft-ietf-tls-dtls13-41: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To an
This is more complicated than I would have liked, but I also don't see how
to simplify it. As of now, I think it's the best we can do.
-Ekr
On Thu, Mar 25, 2021 at 5:05 PM Christopher Patton wrote:
> Hi all,
>
> One of the open issues for ECH is how it interacts with HelloRetryRequest
> (HRR).
On Fri, Mar 26, 2021 at 9:30 AM Christopher Patton wrote:
> I really like this idea, but I don't see it as a solution to ECH's HRR
> woes. NIck's idea boils down to providing a recipe for how to construct the
> CHOuter, but AFAICT, there's nothing in the TLS or HTTPS-RR specs that
> requires the
Hi folks,
This is a combined response to Martin Duke and to Mark Allman.
Before I respond in detail I'd like to level set a bit.
First, DTLS does not provide a generic reliable bulk data transmission
capability. Rather, it provides an unreliable channel (a la UDP).
That channel is set up with a
On Fri, Mar 26, 2021 at 3:08 PM Eric Rescorla wrote:
> Hi folks,
>
> This is a combined response to Martin Duke and to Mark Allman.
>
> Before I respond in detail I'd like to level set a bit.
>
> First, DTLS does not provide a generic reliable bulk data transmissio
Thanks for the discussion. I have pushed the following PR to address your
comments:
https://github.com/tlswg/dtls13-spec/pull/226
Here is a summary of the changes:
- Change the default retransmission timer to 1s and
allow people to do otherwise if they have side knowledge.
- Cap any given flig
On Tue, Apr 20, 2021 at 2:09 PM John Scudder via Datatracker <
nore...@ietf.org> wrote:
> John Scudder has entered the following ballot position for
> draft-ietf-tls-dtls-connection-id-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses incl
On Tue, Apr 20, 2021 at 3:42 PM John Scudder wrote:
> On Apr 20, 2021, at 5:32 PM, Eric Rescorla wrote:
>
> 3. Section 6:
>>
>>* There is a strategy for ensuring that the new peer address is able
>> to receive and process DTLS records. No such strategy
This was addressed in -42.
On Wed, Mar 31, 2021 at 9:38 PM Benjamin Kaduk wrote:
> Hi Martin,
>
> Thanks for starting the separate thread to cover the transport topics.
>
> I'll trim heavily to call out one topic that might benefit from some
> attention from the working group...
>
> On Wed, Mar
I have posted draft-ietf-tls-dtls13-42, addressing the IESG
Feedback. Thanks to everyone who provided reviews. Here is a
description how I handled comments. If there is somebody whose
feedback I missed please let me know.
-Ekr
Erik Kline
> [ section 4.4 ]
>
> * "respectively" -> "respective
Probably not, but I agree with MT.
The general idea here is that any given protocol trace should only be
interpretable in one way. So, either you need the interior protocol to be
self-describing or you need to separate the domains with ALPN. I don't
believe that either the IP ACL or mTLS addresses
r us to know about it in March when the WG moved the draft to WGLC,
> Directorates Review, and IETF LC
>
I don't think anyone is saying that the WG somehow did something wrong
procedurally, merely that this is a defect that ought to be corrected prior
to publication.
-Ekr
On Thu, Apr 2
visible to the application if a library
> were to default to use of ECH where possible).
>
Correct. The purpose of ALPN in this context is to avoid cross-protocol
attacks on the endpoints. Reliance on them by intermediaries is difficult
absent some fairly strong assumptions about the e
I'm not sure precisely what attacks you are referring to here. In
particular, I'm not aware of any known security issues with HMAC-SHA1. With
that said, I agree that we wouldn't choose AES_128_CBC_SHA as a default
now, but this isn't usually the kind of thing we would usually use an
erratum for. Ra
Hi Florian,
This suggestion comes up occasionally, and as Rich Salz says,
you could just register your own cipher suite.
With that said, I would make three comments:
1. I think it's a bit of a category error to talk about AEAD versus
non-AEAD in this context. AEAD is just an interface, so it's p
when the confidentiality key is leaked is possible, but that
won't address the issue of not
being able to reason about the security properties. That's primarily an
issue for upper-level protocols
not TLS.
-Ekr
> On Mon, May 17, 2021 at 3:01 PM Eric Rescorla wrote:
>
>> Hi F
I've heard the phenomenon called "exhaustion" and "rekey" the fix for it.
On Thu, Jun 24, 2021 at 11:52 AM Salz, Rich wrote:
> Rekey and safety margin work for my purposes. Thanks everyone!
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.or
On Fri, Jun 25, 2021 at 7:21 AM Stephen Farrell
wrote:
>
> Hiya,
>
> If a client established a session to foo.example.com
> using ECH with a public_name of example.com, what ought
> the client put in the SNI when resuming?
>
> Ignoring ECH, 8446 seems to imply one ought put in
> foo.example.com [
Hi folks,
I have just given draft-celi-wiggers-tls-authkem-00.txt a quick
read. I'm struggling a bit with the rationale, which I take to be
these paragraphs:
In this proposal we use the DH-based KEMs from [I-D.irtf-cfrg-hpke].
We believe KEMs are especially worth discussing in the context o
0] Or the server can send a Retry packet, incurring a round trip, but this
only needs to be done the first time as long as the client's IP doesn't
change.
> > On Jul 12, 2021, at 20:30, Eric Rescorla wrote:
> >
> > Hi folks,
> >
> > I have just given draft-ce
As we are currently working on a 8446-bis, the best thing to do would be to
file a PR at:
https://github.com/tlswg/tls13-spec
Thanks,
-Ekr
On Thu, Jul 15, 2021 at 3:56 AM Peter Gutmann
wrote:
> I've got some code that dumps TLS diagnostic info and realised it was
> displaying garbage values fo
I support adoption
On Thu, Jul 29, 2021 at 12:00 PM Benjamin Beurdouche <
benjamin.beurdou...@inria.fr> wrote:
> I support adoption.
> B.
>
> > On Jul 29, 2021, at 10:22 PM, Christopher Wood
> wrote:
> >
> > Based on positive feedback during this week's meeting, we'd like to
> start an adoption
FWIW, the situation Rich outlines has been true for all prior versions of
TLS as well; it's just that TLS 1.3 is so different that there's a lot more
advantage to doing TLS 1.3 only than (say) doing TLS 1.2 but not TLS 1.1.
This isn't the question asked, but for the most part, ClientHellos
generat
On Thu, Aug 5, 2021 at 2:37 PM Toerless Eckert wrote:
> Thanks for the explanation.
>
> My main concern was just to understand clearly what requirements
> have to be written into RFC when one wants to ensure that TLS 1.2 needs
> to be supported as the fallback in a particular solution.
>
> With
also nicely fit into
> something like that. Maybe something for opsec wg..
>
This is in the next section:
https://tools.ietf.org/rfcmarkup?doc=8446#appendix-D.3
-Ekr
> Cheers
> Toerless
>
> (*) Not sure about the number. Could have been egyption or chinese history
> ;-)
This document seems generally fine. I agree with MT that the security
considerations could be beefed up.
On Wed, Aug 11, 2021 at 3:53 PM Carrick Bartle wrote:
> Okay, in that case, I wouldn't use the word "re-validated," since to me
> that sounds like the certificate is to be completely validate
On Tue, Aug 17, 2021 at 10:41 AM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> > Regardless of the Raccoon attack, the static DH and ECDH ciphersuites
> do not provide
>
> > forward secrecy,
>
>
>
> Unless you use semi-static exchange, which in many cases makes sense.
>
>
>
> > w
On Tue, Aug 17, 2021 at 5:09 PM Martin Thomson wrote:
> I don't think that this approach is the best we could do.
>
> Experiments, particularly large-scale ones, turn into deployments.
> Consequently the difference between "an experiment" and "a standard" is the
> date at which you look. See als
I don't believe that this document should update 8446. As noted in S 1, we
didn't define these bindings because we didn't have complete analysis. This
document doesn't seem to either contain or reference such analysis and
until we have that, I think RFC 8446 shouldn't be retconned into endorsing
th
mplications of "updates". We are currently preparing an 8446-bis.
What would you have that document say about this topic?
-Ekr
> —Sam
>
>
> On Fri, Oct 1, 2021, at 18:49, Eric Rescorla wrote:
> > I don't believe that this document should update 8446. As noted in
I want to be clear that I don't think this is about credit. My concern is
purely about accurately reflecting the level of confidence one should have
in this mechanism.
-Ekr
On Fri, Oct 1, 2021 at 8:43 PM Sam Whited wrote:
> This is just a registration with IANA more than anything else; this
>
updates implied confidence (though I don't think
> it does), TLS alread implies confidence in its own EKM mechanism. I
> don't believe this document expands on that. For example, it does not
> detail any particular use of channel binding.
>
> —Sam
>
>
> On Sat,
On Tue, Oct 5, 2021 at 6:36 PM Martin Thomson wrote:
> I left a comment, but I don't think that the fix, as it is specifically
> proposed, works.
>
> The general shape of the proposal seems credible. A larger epoch space,
> of which we only send the least-significant bits, would seem to address
I am actually not in favor of changing it to IETF Consensus. I think these
have different meanings.
I prefer: Recommended/Not Recommended/Discouraged
On Fri, Oct 29, 2021 at 7:37 AM Salz, Rich wrote:
>
>- I agree that the "Recommended" column in the IANA registry (which is
>frequently
Previous discussion is on this issue:
https://github.com/tlswg/tls13-spec/issues/1214
On Fri, Oct 29, 2021 at 12:13 PM Salz, Rich wrote:
>
>- I am actually not in favor of changing it to IETF Consensus. I think
>these have different meanings.
>
>
>
> To be clear, I wasn’t expressing an o
TO Printer Working Group IPP
> WG - successor to IETF IPP WG in the 1990s).
>
> Cheers,
> - Ira
>
>
> On Fri, Oct 29, 2021 at 3:18 PM Eric Rescorla wrote:
>
>> Previous discussion is on this issue:
>> https://github.com/tlswg/tls13-spec/issues/1214
>>
>&
ated might also be new stuff we
think is bad, not just old stuff.
-Ekr
>
> On Fri, Oct 29, 2021 at 5:17 PM Eric Rescorla wrote:
>
>> Well, we certainly can change it in 8446-bis.
>>
>> My put here would be: let's get consensus on the *semantics* we want for
>&g
FWIW, while I don't think we should be doing much enhancement of (D)TLS
1.2, I also don't think it makes sense not to allow enhancements to 1.3 to
be used with 1.2 where that makes sense, as it seems to here.
-Ekr
On Thu, Nov 4, 2021 at 11:05 AM Achim Kraus wrote:
> Hi Sean,
>
> I hope, the an
I'm trying to recall why that text exists. I think the idea wasn't that you
actually couldn't start processing it but that you had to keep it rather
than discard it.
Without thinking it through completely, I think it would probably be safe
to add something about gradual processing, but your text s
discards out of order records
will require N round trips in order to receive
the entire flight. This doesn't seem good. For this reason, I think we
should strongly encourage/require buffering.
Re (2), I think we could just add a sentence saying that it was legal to
process any in-order data
d the reassembly buffer to (700,2000). That's a valid
> strategy, isn't it?
>
I believe that will work, yes.
-Ekr
--
> *From:* Eric Rescorla
> *Sent:* Sunday, November 7, 2021 9:14 PM
> *To:* Hanno Becker
> *Cc:* Scott Fluhrer (sfluhrer)
essing of fragments (if possible), or a combination of both.
>
This doesn't accomplish the goal of having a clear set of behaviors which
endpoints can engage in. It's just a requirement.
-Ekr
> --
> *From:* Eric Rescorla
> *Sent:* Sunday, No
"?
>
That would be fine with me.
-Ekr
> --
> *From:* Eric Rescorla
> *Sent:* Sunday, November 7, 2021 10:16 PM
> *To:* Hanno Becker
> *Cc:* Scott Fluhrer (sfluhrer) ; Achim Kraus <
> achimkr...@gmx.net>; tls@ietf.org
> *Sub
that this works. Because it allows you to simply drop it.
If you want to file an issue, I will attempt to draft some text.
-Ekr
>
>
> --
> *From:* Eric Rescorla
> *Sent:* Monday, November 8, 2021 11:47 AM
> *To:* Hanno Becker
> *Cc:* Scott Fluhrer (sfluhrer) ; Achim Kraus &
On Mon, Nov 8, 2021 at 4:12 AM Salz, Rich wrote:
>
>- No. As I indicated in my earlier, email, while that scheme may
>technically work, it is potentially highly inefficient and I think we
>should discourage it.
>
>
>
> To be clear, not something we need to address here and now.
>
>
>
I am fine with this change.
On Thu, Nov 11, 2021 at 11:36 PM John Mattsson wrote:
> Hi,
>
>
>
> My biggest concern with the "Recommended" column that I raised some year
> ago is that most people I meet in other SDOs as well as developers using
> TLS tend to believe that "Recommended" means "Reco
Thanks, Chris.
At a high level, I think we should be focusing our efforts on TLS 1.3.
That means that we should design new features for 1.3 and not for 1.2,
but if it's straightforward to also specify them for 1.2, this is
potentially worthy of consideration on a case-by-case basis.
We generally
I'd probably reserve slightly more for standards action, maybe the first 24
bits. Otherwise, I agree with MT.
-Ekr
On Sun, Dec 12, 2021 at 12:51 PM Yoav Nir wrote:
> Well, that’s two voices for Martin’s PR and just me liking the convoluted
> text that I wrote.
>
> Chairs, care to call consensu
s. (We
> could also make it 7 or lower so we're not wasting an empty octet for this
> flag, should folks want to go that route.)
>
> Any objections?
>
> Best,
> Chris
>
> On Sun, Dec 12, 2021, at 2:22 PM, Eric Rescorla wrote:
> > I'd probably reserve slight
On Wed, Jan 5, 2022 at 7:18 PM Martin Thomson wrote:
> These are both disruptive changes, but I agree that they are OK in
> principle.
>
> I have a few questions on #257. Those are on the PR, but I'll repeat them
> here:
>
> Many implementations of DTLS use a 16-bit integer to hold epoch.
> Some
Hi Douglas,
8446 already says:
Note that HKDF-Expand implements a pseudorandom function (PRF) with
both inputs and outputs of variable length. In some of the uses of
HKDF in this document (e.g., for generating exporters and the
resumption_master_secret), it is necessary that the appl
TLS 1.3 supports certificate-based client auth in the primary handshake.
-Ekr
On Fri, Jan 14, 2022 at 8:19 AM Urmas Vanem wrote:
> Hello!
>
>
>
> TLS 1.3 introduces post-handshake authentication. It relies on
> client/browser, client/browser must send post_handshake_auth extension to
> server
On Wed, Jan 19, 2022 at 6:57 AM Yaron Sheffer wrote:
> Hi,
>
>
>
> RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to
> use OCSP and OCSP stapling. We are changing these recommendations [2] in
> view of OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961.
>
>
>
> But th
This discussion seems kind of out of scope for 7525-bis, which is about how
to use TLS, but doesn't seem to say much of anything in terms of how to
operate a CA.
The current draft seems not to say anything about what clients ought to do
and to say that servers SHOULD support OCSP and OCSP stapling
On Tue, Feb 1, 2022 at 11:55 AM Stefan Santesson wrote:
> Hi,
>
> This issue is currently discussed in the LAMPS WG. The background is
> that X.520 removed the size limitations of the common X.520 attributes
> in 2008, while they are still enforced in RFC 5280.
>
> I don't want to move this discu
I agree with MT. The right way to think of this extension is as a
compression mechanism that matches the semantics of otherwise empty
extensions. And in that case, we should retain the semantics of not echoing
the extension, which is to say "I didn't accept it, whether I know about it
or not"
-Ek
Precisely.
On Mon, Feb 21, 2022 at 2:42 PM Martin Thomson wrote:
> On Tue, Feb 22, 2022, at 09:09, Benjamin Kaduk wrote:
> > I think (but don't have a solid recollection) that this may have
> > stemmed from a desire for the sender to know if the recipient supports
> > flags at all. But thinking
I think it would probably be better to require it to be sent even if empty.
Then you could measure how often it was implemented.
On Mon, Feb 21, 2022 at 9:36 PM Yoav Nir wrote:
> I have just submitted PR #20 to allow unacknowledged flags. It is a
> rewrite of section 3 (rules)
>
> https://githu
On Wed, Feb 23, 2022 at 6:25 AM Salz, Rich wrote:
> >It is probably "best" (for some definition of "best") to publish an
> RFC
> that Updates: 9102 and has the revised directive to IANA.
>
> I hope that is excessive.
>
> >Probably an errata report should be filed against RFC 9102 rega
I support adoption.
On Wed, Feb 23, 2022 at 10:45 AM Salz, Rich wrote:
> Oops. Reply over reply-all, not common :)
>
> On 2/23/22, 12:34 PM, "Christopher Wood" wrote:
>
> Oops — I think you accidentally replied only to me. Would you mind
> replying on the list as well?
>
> > On Feb 1
Note that a password manager is a partial mitigation here, at least if it's
tied into the browser and automatically fills in based on origin, much like
WebAuthn is.
-Ekr
On Mon, Apr 11, 2022 at 3:13 PM Richard Barnes wrote:
> Just to be clear:
>
> * These "picture in picture" attacks have been
Consider the case where the client wants to offer some capability that
the server then responds to with real data, rather than just an
acknowledgement.
For instance, supposing the SCT extension from RFC 6962 did not exist,
the client would want to indicate support in CH and the server would
send t
On Wed, Apr 13, 2022 at 3:51 PM Benjamin Kaduk wrote:
> On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> > Consider the case where the client wants to offer some capability that
> > the server then responds to with real data, rather than just an
> > acknowl
n 14 Apr 2022, at 1:51, Benjamin Kaduk 40akamai@dmarc.ietf.org> wrote:
> >
> > On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> >> Consider the case where the client wants to offer some capability that
> >> the server then responds to w
On Mon, May 9, 2022 at 8:43 AM Benjamin Kaduk wrote:
> On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir wrote:
> >
> >
> > > On 14 Apr 2022, at 1:51, Benjamin Kaduk 40akamai@dmarc.ietf.org> wrote:
> > >
> > > On Wed, Apr 13, 2022 at 10:56:49A
On Fri, May 27, 2022 at 6:27 AM Robert Moskowitz
wrote:
> Is there any activity to define SCHC rules for DTLS?
>
Not to my knowledge.
-Ekr
>
> I want this for Unmanned Aircraft (UA) Network Remote ID (Net-RID)
> communications from the UA to the Net-RID Service Provider (SP).
>
> See
>
> http
I took a quick look at this draft. A few comments follow.
VENUE
The correct venue for this work is the TLS WG. This is a relatively
straightforward piece of work that is clearly within the TLS WG's
charter scope ("This includes extensions or changes that help
protocols better use TLS as an authen
301 - 400 of 1635 matches
Mail list logo
