On Sun, Oct 20, 2019 at 2:41 PM Rob Sayre wrote:
> Hi,
>
> I was implementing https://tools.ietf.org/html/draft-ietf-tls-esni-02
> (since I believe that version is what Firefox and Cloudflare currently
> ship), and I had a difficult time parsing this part of the draft:
>
> struct {
> ServerName
On Mon, Oct 21, 2019 at 7:32 AM Rob Sayre wrote:
> Judging by the mailing list archives, the design of the field is
>>> intentional. It's not clear to me why "zeros" wasn't specified as
>>> variable-length with a prose restriction, though.
>>>
>>
>> Because then you have a spurious length field
On Mon, Oct 21, 2019 at 7:56 AM Rob Sayre wrote:
> On Mon, Oct 21, 2019 at 7:41 AM Eric Rescorla wrote:
>
>>
>>
>> On Mon, Oct 21, 2019 at 7:32 AM Rob Sayre wrote:
>>
>>
>>
>>> Judging by the mailing list archives, the design of the field is
On Mon, Oct 21, 2019 at 10:55 AM Rob Sayre wrote:
> On Mon, Oct 21, 2019 at 9:45 AM Eric Rescorla wrote:
>
>>
>>
>> On Mon, Oct 21, 2019 at 7:56 AM Rob Sayre wrote:
>>
>>> Sorry if I'm being dense here. Couldn't "zeros" hav
On Mon, Oct 21, 2019 at 11:41 AM Stephen Farrell
wrote:
>
> Hiya,
>
> On 21/10/2019 19:08, Eric Rescorla wrote:
> > No. You want padding to be set to be the longest size that you would send
> > to any origin in the anonymity group, and the server knows this.
>
>
On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 21/10/2019 20:29, Eric Rescorla wrote:
>
> > The question is not the server, but the operator.
>
> Sure, but the point holds though. If ESNIKeys are changed every
> N seconds, and any new cer
On Mon, Oct 21, 2019 at 1:07 PM Rob Sayre wrote:
> On Mon, Oct 21, 2019 at 1:03 PM Eric Rescorla wrote:
>
>> On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell <
>> stephen.farr...@cs.tcd.ie> wrote:
>>
>>>
>>>
>>> Not yet, that's t
On Mon, Oct 21, 2019 at 1:46 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 21/10/2019 21:02, Eric Rescorla wrote:
> >> Sure, but the point holds though. If ESNIKeys are changed every
> >> N seconds, and any new certificate is loaded during that time,
> >>
On Tue, Oct 22, 2019 at 10:49 AM Stephen Farrell
wrote:
>
>
> On 22/10/2019 17:44, Salz, Rich wrote:
> > I think varying padding to some fixed multiple is a good trade-off.
>
> Me too. I'd go for multiples of 32 octets, with a SHOULD
> to add an extra block or two randomly, but anything of
> that
On Tue, Oct 22, 2019 at 11:15 AM Stephen Farrell
wrote:
>
>
> On 22/10/2019 19:10, Eric Rescorla wrote:
> > Uh,why?
>
> Openness, transparency, enabling the WG to make decisions on
> the list.
The WG has the chance to make decisions on the list *in response to*
proposa
On Tue, Oct 22, 2019 at 11:30 AM Salz, Rich wrote:
> Sure, it’s allowed to work this way.
>
>
>
> Not sure, since there is very active discussion going on in the WG email
> right now, that it is the best way.
>
>
>
> Not everything is always done the best way. But maybe we can all try
> harder?
Are you suggesting that these strings appear on the wire in DNS? Or is this
just an internal implementation covnenience?
-Ekr
On Fri, Oct 25, 2019 at 3:55 AM Stephen Farrell
wrote:
>
> Hiya,
>
> To date, my ESNI code [1] has been dealing with files containing
> the binary encoding of ESNIKeys
On Fri, Oct 25, 2019 at 7:03 AM Stephen Farrell
wrote:
>
>
> On 25/10/2019 14:45, Eric Rescorla wrote:
> > Are you suggesting that these strings appear on the wire in DNS?
>
> Nope.
>
> > Or is this
> > just an internal implementation covnenience?
>
&g
On Fri, Oct 25, 2019 at 7:11 AM Stephen Farrell
wrote:
>
>
> On 25/10/2019 15:06, Eric Rescorla wrote:
> > OK. I don't think this needs to be documented in this draft, but if you
> > wanted to write some other draft
>
> It doesn't *need* to be in draft-i
I have some concerns here that I floated in the bug.
At a high level, ipv[46]hints seems like a regression from the way things
are in ESNI.
-Ekr
On Fri, Oct 25, 2019 at 9:01 AM Tommy Pauly wrote:
> I'm also supportive of this change, and in general of using HTTPSSVC for
> the transmission of
On Fri, Nov 1, 2019 at 2:28 PM Rob Sayre wrote:
> Hi,
>
> I am not sure how important these findings are, but I've noticed three
> instances of unnecessarily predictable inputs in ESNI:
>
> 1) Trailing padding after domain names are zeros.
>
2) The checksum calculation seems to start with predict
On Fri, Nov 1, 2019 at 3:27 PM Rob Sayre wrote:
> On Fri, Nov 1, 2019 at 3:09 PM Eric Rescorla wrote:
>
>>
>>
>> On Fri, Nov 1, 2019 at 2:28 PM Rob Sayre wrote:
>>
>>> Hi,
>>>
>>> I am not sure how important these findings are, but I&#x
On Fri, Nov 1, 2019 at 3:54 PM Rob Sayre wrote:
>
>
> On Fri, Nov 1, 2019 at 3:39 PM Eric Rescorla wrote:
>
>>
>>>>
>>> I see. But is there any reason to make these inputs predictably zero by
>>> spec?
>>>
>>
>> Abse
On Tue, Nov 5, 2019 at 1:58 PM Rob Sayre wrote:
> On Tue, Nov 5, 2019 at 12:35 PM Christopher Wood
> wrote:
>
>> >
>> > The attacks on ESNI security above seem to stem from two problems:
>> >
>> > 1. The ESNI contents are not fully bound to the ClientHello contents.
>>
>
> This seems right to me
On Tue, Nov 5, 2019 at 2:31 PM Rob Sayre wrote:
>
>
> On Tue, Nov 5, 2019 at 2:15 PM Eric Rescorla wrote:
>
>>
>>
>> On Tue, Nov 5, 2019 at 1:58 PM Rob Sayre wrote:
>>
>>> On Tue, Nov 5, 2019 at 12:35 PM Christopher Wood
>>> wrote:
>&g
I have filed a PR to fix this.
On Wed, Nov 6, 2019 at 10:28 PM Ilari Liusvaara
wrote:
> On Thu, Nov 07, 2019 at 11:18:28AM +1100, Martin Thomson wrote:
> > > Omitting the length field MUST only be used for data which is
> > > protected with one of the application_traffic_secret values, and
> > >
On Mon, Nov 11, 2019 at 2:59 PM Martin Thomson wrote:
> Since Rob quoted this:
>
> On Tue, Nov 12, 2019, at 09:42, Rob Sayre wrote:
> > with the exception that there is no DTLS version of SSLv2 or SSLv3,
>
> also on this list is TLS 1.0. DTLS 1.0 is TLS 1.1.
>
Yes, but that's presumably an
On Mon, Nov 11, 2019 at 2:43 PM Rob Sayre wrote:
> On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben wrote:
>
>> The one concrete one that I remember (and can't attribute to the HTMLized
>> version dropping stuff) is RFC 7030 only in the header.
>>
>> I guess we can check what we want to do to DTLS as
On Tue, Nov 12, 2019 at 9:56 AM Rob Sayre wrote:
>
>
> On Tue, Nov 12, 2019 at 7:58 AM Eric Rescorla wrote:
>
>>
>>
>> On Mon, Nov 11, 2019 at 2:43 PM Rob Sayre wrote:
>>
>>> On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben wrote:
>>>
>>
To recap what I was saying at the microphone earlier today about
selfie/reroute issues, there are actually three separate issues.
- A reflection attack where an outside attacker makes the client also
act as a server.
- A reroute attack where an outside attacker makes the client talk to
anothe
I support adoption.
On Wed, Nov 20, 2019 at 9:36 PM Sean Turner wrote:
> At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG
> and the LAKE BOF, which is now a chartered WG [3]. After some discussions,
> the ADs suggested [4] that the TLS WG consider whether this draft be
I favor adoption
On Wed, Nov 20, 2019 at 10:56 PM Sean Turner wrote:
> At IETF 106 there was support for adoption of "Batch Signing for TLS" [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 chairs know by
>
+1
On Thu, Nov 21, 2019 at 7:30 PM wrote:
> I am in favor of adopting this document as a starting point for further
> work. It fits nicely into the work on cTLS
>
> -Original Message-
> From: TLS On Behalf Of Sean Turner
> Sent: Friday, November 22, 2019 6:29 AM
> To: TLS List
> Subjec
On Sun, Nov 24, 2019 at 10:46 PM Rob Sayre wrote:
> Hi,
>
> This client now interoperates with Cloudflare and the https://defo.ie
> copy of OpenSSL. It's tri-licensed under the Apache 2, MIT, and ISC
> licenses. It won't be merged until draft-06 is out, at a minimum.
>
> https://github.com/ctz/ru
On Tue, Nov 26, 2019 at 10:05 PM Xuan k wrote:
> Hi all,
>
> I'm trying to implement a DTLS1.3 library for embedded devices. But It
> seems something weird about retransmissions and ACKs.
>
> In the section "5.2. DTLS Handshake Message Format":
>
>The first message each side transmits in each
; message_seq = 0 is used by the first ClientHello which is the one without
> cookies.
>
I agree in principle, but that's not this example, because, as you can see,
there is no HRR. Rather, this needs to remove +cookie.
-Ekr
> Thanks,
> Zhai Zhaoxuan
>
> On 11/28/19 5:3
On Thu, Dec 19, 2019 at 5:54 AM Alissa Cooper via Datatracker <
nore...@ietf.org> wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-tls-tls13-cert-with-extern-psk-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addr
Hmm... There doesn't seem to be any content. Perhaps mis-filed?
On Fri, Jan 3, 2020 at 9:20 PM RFC Errata System
wrote:
> The following errata report has been submitted for RFC5246,
> "The Transport Layer Security (TLS) Protocol Version 1.2".
>
> --
> You may
LGTM
On Thu, Jan 16, 2020 at 7:32 PM Christopher Wood
wrote:
> Hi folks,
>
> As discussed in Singapore, it's time to re-charter the working group to
> reflect ongoing (e.g., Exported Authenticators and Encrypted SNI/CH) and
> future work (e.g., cTLS). For reference, the current charter is availa
I am willing to contribute.
-Ekr
On Tue, Jan 21, 2020 at 2:50 AM Jonathan Hoyland
wrote:
> Hi All,
>
> This is something I'm very interested in.
>
> Definitely want to participate.
>
> Regards,
>
> Jonathan
>
> On Tue, 21 Jan 2020 at 10:04, Mohit Sethi M 40ericsson@dmarc.ietf.org> wrote:
I agree with Martin that this is unnecessary complexity.
In addition, I would note that switching to a new ticket *does* help even
if the server is using the same STEK because it improves privacy.
-Ekr
On Tue, Jan 21, 2020 at 12:58 AM Martin Thomson wrote:
> On Tue, Jan 21, 2020, at 16:54, Vi
I would make several points here:
1. RFC 8446 explicitly discourages ticket reuse
(https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we
should not be designing an extension to enable reuse. While it's
potentially true that some applications do not benefit from
non-reuse, crea
> On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote:
>
> > I would make several points here:
> >
> > 1. RFC 8446 explicitly discourages ticket reuse
> >(https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we
> >should not be designing
On Sun, Feb 2, 2020 at 6:43 AM Tommy Pauly wrote:
> > On Feb 2, 2020, at 3:52 AM, Viktor Dukhovni
> wrote:
>
> On the other hand, the proposed sentinel value indicates “I’d like to
> reuse tickets if I can”, but without any additional signaling from the
> server about the support of ticket reuse
On Sun, Feb 2, 2020 at 9:53 AM Viktor Dukhovni
wrote:
> Yes, that's because reuse does not need multiple tickets. Indeed long
> ago upthread we discussed the fact that multiple tickets should
> generally only happen on full handshakes (or at least infrequently,
> rather than on each resumption).
On Sun, Feb 2, 2020 at 11:04 AM Nico Williams wrote:
> On Sun, Feb 02, 2020 at 09:08:17AM -0800, Eric Rescorla wrote:
> > I'm sorry to say that I'm not that sympathetic to this position. I
> > appreciate that it's inconvenient for Postfix to have frequent writes
>
On Sun, Feb 2, 2020 at 7:40 PM Rob Sayre wrote:
> On Sun, Feb 2, 2020 at 11:52 AM Daniel Migault 40ericsson@dmarc.ietf.org> wrote:
>
>>
>> On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla wrote:
>>
>>>
>>>
>>> 1. TLS 1.3 takes the posi
I agree. This was an intentional change.
-Ekr
On Tue, Feb 4, 2020 at 7:19 AM Russ Housley wrote:
> I think the document is correct and the IANA registry should remove the
> dot.
>
> Russ
>
>
> > On Feb 4, 2020, at 10:13 AM, RFC Errata System <
> rfc-edi...@rfc-editor.org> wrote:
> >
> > The fo
On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre wrote:
> Hi,
>
> I'm not sure how violations of these requirements would result in
> poor interoperability:
>
>Clients which import external keys TLS MUST NOT use these keys for
>any other purpose. Moreover, each external PSK MUST be associated
>
Hanno,
Thanks for your note. I don't think your proposal will be an
improvement. It destroys information which could otherwise be used for
improve round-trip and loss estimation (cf. the difference between
QUIC and TCP ACKs). Second, it prevents the receiver from saying
some non-sensical things li
On Sun, Mar 1, 2020 at 11:20 PM Viktor Dukhovni
wrote:
> On Sun, Mar 01, 2020 at 10:39:07PM -0800, Rob Sayre wrote:
>
> > > Agreed, and strongly so with the last sentence.
> >
> > None of these messages have addressed the chairs' suggestion:
> >
> > "Consider adoption of an individual draft that
I concur with MT's proposal
On Wed, Mar 4, 2020 at 3:42 PM Martin Thomson wrote:
> I have a third option (mu?) which differs from previous proposals.
>
> I have been somewhat convinced by the arguments about how resumption is
> different and can tolerate the complexity of the additional counter
[Trimming extensively]
On Wed, Mar 4, 2020 at 7:05 PM Viktor Dukhovni
wrote:
> Reuse may never be specified, and worst case there'll be two ways to say
> "give me at most one ticket on resumption", with "at most 1" meaning
> "1" in that version of reality. The two ways being sending either "0"
Hanno,
> Hi Ekr,
>
> thanks for your prompt reply.
>
> > Thanks for your note. I don't think your proposal will be an
> > improvement. It destroys information which could otherwise be used for
> > improve round-trip and loss estimation (cf. the difference between
> > QUIC and TCP ACKs).
>
> What
Hanno,
I do think you are overcomplicating things somewhat.
You can't process handshake messages out of sequence even if they are
received out of sequence (this is, of course, also the case in TLS,
it's just that the resequencing happens at the TCP layer). You have to
either drop out of order mes
This is great news. Thanks for helping make it happen!
-Ekr
On Fri, Mar 6, 2020 at 4:03 PM John Mattsson wrote:
> Hi,
>
> I am happy to report that 3GPP just took the decision to forbid support of
> MD5 and SHA-1, as well as all non-AEAD and non-PFS cipher suites in TLS.
> The changes apply to
Hi folks,
I have just submitted -35.
This makes the following notable changes:
- Fix contradictory text around the legacy cookie field by requiring it to
be empty.
- Note that you can't ACK records unless you are processing the contents
(as noted by Hanno).
It also fixes a few editorial problem
I tend to agree. there's an open issue in the spec about this and I've sort
of come to the conclusion that it's going to be pretty easy to determine
just by sending your own ECH with the same key id and looking at what comes
back.
On Mon, Mar 9, 2020 at 8:32 AM Christopher Wood wrote:
> On Mon,
And -36 is now out, with some more editorial changes and changing the ACK
code point to avoid collisions.
On Sat, Mar 7, 2020 at 2:24 PM Eric Rescorla wrote:
> Hi folks,
>
> I have just submitted -35.
>
> This makes the following notable changes:
>
> - Fix contradictory t
Oops, and 37 because I missed a spot.
On Mon, Mar 9, 2020 at 9:36 AM Eric Rescorla wrote:
> And -36 is now out, with some more editorial changes and changing the ACK
> code point to avoid collisions.
>
> On Sat, Mar 7, 2020 at 2:24 PM Eric Rescorla wrote:
>
>> Hi fol
On Tue, Mar 10, 2020 at 6:48 AM Zhai Zhaoxuan wrote:
> Hi Eric,
>
>
> The new version(-37) says:
>
> After the handshake, ACKs SHOULD be sent once for each received
> and processed record (potentially subject to some delay) and MAY
> cover more than one flight.
>
>
> Does "received and processed
On Sun, Mar 22, 2020 at 2:49 PM Jonathan Hoyland
wrote:
> I'm worried that it'll be too tempting for orgs and Governments to just
> drop sessions which have negotiated ECHO.
>
Well, those orgs will also be able to block encrypted DNS, without which
ECHO is useless. We don't have an answer for th
I think we should relax this requirement. It's turning out to be hard
enough to design ECHO as-is.
If/when we get ECHO fully designed and widely deployed, we can then try to
find designs which use the same basic design but are more stealthy.
Trying to fix everything at once makes the best the ene
Thanks. This seems like a good improvement. I have filed
https://github.com/tlswg/dtls13-spec/issues/128 to track it.
On Fri, Mar 27, 2020 at 8:29 AM Hanno Becker wrote:
> I have a minor comment on DTLS 1.3 draft 37.
>
> On the topic of sending ACKs, the draft recommends:
>
> ```
> ACKs SHOULD N
On Mon, Apr 6, 2020 at 7:17 AM Hanno Becker wrote:
> Hi Thomas!
>
> > That said, as currently written, this doesn't seem to work particularly
> well on paths that are lossy, slow, and with small MTUs (or a
> combination thereof), which we need to make sure it's reasonably well
> covered as it hap
I also made a number of comments, but I think it's roughly fine.
-Ekr
On Tue, Apr 7, 2020 at 5:08 PM Martin Thomson wrote:
> I made a few comments on the pull request, but they are minor. Let's do
> this.
>
> On Wed, Apr 8, 2020, at 03:07, Sean Turner wrote:
> > hi TLS WG,
> >
> > During the
Assuming I understand Hanno's proposal, I do not believe that this is in
fact an improvement, as it does not cover the important case where the
record containing the SH is lost and then the rest of the messages from the
server are uninterpretable.
-Ekr
On Thu, Apr 9, 2020 at 4:27 AM Thomas Fossa
On Thu, Apr 9, 2020 at 6:59 AM Thomas Fossati
wrote:
> On 09/04/2020, 14:20, "Eric Rescorla" wrote:
> > Assuming I understand Hanno's proposal, I do not believe that this is
> > in fact an improvement, as it does not cover the important case where
> > the
On Thu, Apr 9, 2020 at 7:28 AM Thomas Fossati
wrote:
> On 09/04/2020, 15:18, "Eric Rescorla" wrote:
> > > On Thu, Apr 9, 2020 at 6:59 AM Thomas Fossati
> wrote:
> > > On 09/04/2020, 14:20, "Eric Rescorla" wrote:
> > > > Assuming I
I have posted a PR to clarify this:
https://github.com/tlswg/dtls13-spec/pull/142
On Tue, Apr 14, 2020 at 1:13 AM Hanno Becker wrote:
> Hi all,
>
> On ACK protection, DTLS 1.3 Draft 37 says in Section 7:
>
>ACK records MUST be sent with an epoch that is equal to or higher
>than the recor
I don't think we should make this change. In the context of this draft, if
the client wants that behavior, it should send {1, 1}.
-Ekr
On Sun, Apr 19, 2020 at 3:23 PM Viktor Dukhovni
wrote:
> I uploaded a small pull request for the ticket request draft:
>
> https://github.com/tlswg/draft-i
On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker wrote:
> Hi all,
>
> To my understanding, DTLS 1.3 defines AEAD additional data for record
> protection
> as the record header as seen on the wire. Quoting Draft 37, Section 4:
>
> ```
>The entire header value shown in Figure 4 (but prior to record
On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla wrote:
>
>
> On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker wrote:
>
>> Hi all,
>>
>> To my understanding, DTLS 1.3 defines AEAD additional data for record
>> protection
>> as the record header as see
cover what is
actually on the wire. I would be strongly opposed to going back on that.
-Ekr
-Ekr
Looking forward to hearing other WG member's views,
> Hanno
> --
> *From:* Eric Rescorla
> *Sent:* Wednesday, April 22, 2020 2:23 AM
> *To:* Hanno Be
> to?
>
I don't recall making that argument.
-Ekr
> Best,
> Hanno
>
>
> Looking forward to hearing other WG member's views,
> Hanno
> --
> *From:* Eric Rescorla
> *Sent:* Wednesday, April 22, 2020 2:23 AM
> *To:* Hanno Becker
> *Cc:* tls@ietf.org
>
it as in
> https://github.com/tlswg/dtls13-spec/pull/143
> > >>>
> > >>> This seems to be a mixture of logical and on-the-wire
> representation, which
> > >>> moreover duplicates the CID in case it is explicitly present in the
> header.
OK but we would expect the peer to process CID-less records if they are
coalesced?
-Ekr
On Wed, Apr 22, 2020 at 6:39 PM Martin Thomson wrote:
>
>
> On Thu, Apr 23, 2020, at 11:24, Eric Rescorla wrote:
> > On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson
> wrote:
> > &
Hi folks,
As I was going through the ACK clarifications, I noticed that we were
requiring explicit ACKs for everything other than post-handshake
client auth, where we allow implicit ACK. This obviously works,
but given that (1) we expect explicit ACK from the client if there
is a user-consent dela
On Thu, Apr 23, 2020 at 12:40 AM Martin Thomson wrote:
> On Thu, Apr 23, 2020, at 11:49, Eric Rescorla wrote:
> > OK but we would expect the peer to process CID-less records if they are
> > coalesced?
>
> I guess so. If we allowed them to drop them, then we're close
hing.
>
> Best,
> Hanno
>
> --
> *From:* TLS on behalf of Eric Rescorla <
> e...@rtfm.com>
> *Sent:* Thursday, April 23, 2020 9:48 PM
> *To:*
> *Subject:* [TLS] Implicit ACKs in post-handshake
>
> Hi folks,
>
> As I was goi
ys involved in preparing a response, an ACK
> SHOULD be sent rather than relying on implicit acknowledgment.
>
That text is already there, thanks to Hanno.
-Ekr
> On Fri, Apr 24, 2020, at 07:25, Eric Rescorla wrote:
> > I don't feel strongly about it, and not changing anything
On Fri, Apr 24, 2020 at 9:20 AM Hanno Becker wrote:
> Hi Chris,
>
> Just a note on the comparison with TLS 1.3.
>
> > I'd like to point to some related work that could shed light on this
> question.
> > The decision for TLS 1.3 was to authenticate all data that is written to
> the wire,
>
> It do
enticating some abstract information, *not*
what is actually on the wire, and that allows the attacker to manipulate
what's on the wire undetected. We have no analysis for the impact of that.
-Ekr
> Best,
> Hanno
>
> --
> *From:* chris -
>
On Fri, Apr 24, 2020 at 11:51 AM chris - wrote:
>
> I don't think that's at all obvious. Again, the problem with the
>> pseudo-header is you are authenticating some abstract information, *not*
>> what is actually on the wire, and that allows the attacker to manipulate
>> what's on the wire undete
On Fri, Apr 24, 2020 at 12:56 PM Thomas Fossati
wrote:
> On 24/04/2020, 19:53, "chris -" wrote:
> > [...] the details of how to decode the data on the wire begin to
> > really matter for the proof (and potentially for an attacker).
>
> I have zero experience with formal security proofs, so I nee
On Fri, Apr 24, 2020 at 2:29 PM chris - wrote:
> But I'd like to hear Chris weigh in on whether he thinks we should have
>> them explicitly in the AD (and whether that should be true in QUIC too).
>>
>
> I would need to study the specs in order to provide an intelligent answer
> here. Off the hip
thoughts.
>
> Best,
> Hanno
> ------
> *From:* chris -
> *Sent:* Saturday, April 25, 2020 6:58 PM
> *To:* Hanno Becker
> *Cc:* Eric Rescorla ; Hannes Tschofenig <
> hannes.tschofe...@arm.com>; tls@ietf.org
> *Subject:* Re: [TLS] Choic
Hi Ben,
Thanks for your note and for your efforts on the tutorial!
On Wed, Apr 29, 2020 at 5:43 AM Ben Smyth wrote:
> Section 4.2.10 requires a server receiving early data to behave in ways
> including (p53):
>
> * Ignore the extension and return a regular 1-RTT response. The server
> then ski
On Thu, Apr 30, 2020 at 2:40 AM Ben Smyth wrote:
> Section 4.2.11.1 explains that:
>
> ...PskIdentity contains an obfuscated version of the ticket age formed by
> taking the age in milliseconds and adding the "ticket_age_add"... This
> addition prevents passive observers from correlating connecti
On Thu, Apr 30, 2020 at 2:46 AM Ben Smyth wrote:
> Section 4.2.10 requires a server receiving early data to behave in ways
>>> including (p53):
>>>
>>> * Ignore the extension and return a regular 1-RTT response. The server
>>> then skips past early data by attempting to deprotect received record
I rather prefer ECHO.
-Ekr
On Fri, May 8, 2020 at 9:31 AM Erik Nygren wrote:
> +1 to "ETCH"
>
> Any objections to that or concerns with that?
> (Agreed it would be good to finalize this ASAP.)
>
> On Thu, May 7, 2020 at 7:03 PM Tommy Pauly 40apple@dmarc.ietf.org> wrote:
>
>> ECHO is more
On Wed, May 6, 2020 at 1:09 AM Ben Smyth wrote:
> As far as I can tell, secret [sender]_handshake_traffic_secret is computed
> over transcript CH || SH or CH || HRR || CH || SH. (A server can compute
> their secret once they've computed SH, whereas a client must wait until
> they've received SH b
On Tue, May 5, 2020 at 10:55 AM Felix Günther
wrote:
> 4) I slightly disagree with "epochs determine the key" (true) as, what
> I understand is, an argument that "the full epoch is implicitly
> authenticated by using the right key", at least in its absoluteness. My
> *guess* would be that, due
If we must change it, let's do ECH, as the T seems entirely superfluous.
After all, it's not TSNI.
-Ekr
On Tue, May 19, 2020 at 5:32 AM Sean Turner wrote:
> I am glad this bikeshed was shorter than I expected. Because most people
> didn’t have a strong preference and there might be some (possi
This would be my preferred resolution
On Thu, May 21, 2020 at 8:59 AM Christopher Wood
wrote:
> PR #148 in the DTLS 1.3 draft (
> https://github.com/tlswg/dtls13-spec/pull/148) proposes banning implicit
> CIDs. This comes at an obvious cost in terms of bytes on the wire. However,
> in discussion
I actually already merged it :)
On Thu, May 21, 2020 at 12:48 PM Christopher Wood
wrote:
> To make it official, here's a PR making that change:
>
>https://github.com/tlswg/draft-ietf-tls-esni/pull/236
>
> Please have a look. I'll merge in the next day or so.
>
> Thanks!
> Chris (no hat)
>
>
We have already implemented ECH (old versions) for NSS and are eager to
deploy it in Firefox.
We are likely to implement cTLS.
-Ekr
On Fri, May 22, 2020 at 6:20 AM Salz, Rich wrote:
> I am reluctant to make CTLS standards-track without a statement from
> someone that they are likely to implem
On Sun, May 24, 2020 at 11:01 AM Thomas Fossati
wrote:
> On 22/05/2020, 01:09, "Christopher Wood" wrote:
> > On Thu, May 21, 2020, at 9:22 AM, Thomas Fossati wrote:
> > > Hi Chris,
> > >
> > > On 21/05/2020, 17:00, "Christopher Wood"
> > > wrote:
> > > > *One proposal to address this is by exte
On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson wrote:
> I think that this is a useful erratum and it should be approved/HFDU. The
> extension to which this text alludes is RFC 8773, not post_handshake_auth.
>
Yes, although 8773 actually is not super-clear about post-handshake, so
that's actually
On Thu, Jun 4, 2020 at 8:46 AM Russ Housley wrote:
> Eric:
>
> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson wrote:
>
>> I think that this is a useful erratum and it should be approved/HFDU.
>> The extension to which this text alludes is RFC 8773, not
>> post_handshake_auth.
>>
>
> Yes, although
On Thu, Jun 4, 2020 at 9:24 AM Russ Housley wrote:
> Eric:
>
> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson wrote:
>>
>>> I think that this is a useful erratum and it should be approved/HFDU.
>>> The extension to which this text alludes is RFC 8773, not
>>> post_handshake_auth.
>>>
>>
>> Yes, a
On Fri, Jun 19, 2020 at 11:03 AM Salz, Rich wrote:
>
>- It seems like it should appear with a "Recommended" value of "No",
>and no value in the TLS 1.3 column, since the document says "The Middlebox
>Security Protocol builds on TLS 1.2". [3]
>
>
>
>- Is that what's being proposed?
On Tue, Mar 1, 2016 at 6:42 PM, Watson Ladd wrote:
> On Mon, Feb 29, 2016 at 6:45 AM, Sean Turner wrote:
> > At the TRON workshop [0], we (Joe and Sean) were asked to provide our
> views about the status and timeline for TLS 1.3; we wanted to share the
> same information with the WG.
> >
> > Bef
On Tue, Mar 1, 2016 at 7:01 PM, Martin Thomson
wrote:
> On 2 March 2016 at 13:55, Eric Rescorla wrote:
> > I think a "safer" profile of TLS, as in "implement the following features
> > (section XXX, YYY) and not the following (section ZZZ)" then that se
On Wed, Mar 2, 2016 at 1:25 AM, Yoav Nir wrote:
>
> > On 2 Mar 2016, at 11:16 AM, Rob Stradling
> wrote:
> >
> > On 02/03/16 09:10, Rob Stradling wrote:
> >
> >>> Neither you nor I can post in any of the CA/Browser forum’s lists,
> >>> because neither of us has either a browser or a public CA.
801 - 900 of 1635 matches
Mail list logo
