Sorry - I have one more I wanted to raise as an issue. Will
do that tomorrow and send a mail,
Cheers,
S.
On 24/04/2020 00:30, Christopher Wood wrote:
> In preparation for next week's virtual interim session on ECHO, I'd like to
> draw your attention to the following issues and PRs we'll be
On Thu, Apr 23, 2020 at 4:58 PM Martin Thomson wrote:
> What makes this case interesting is the non-machine time that might exist
> between receiving CertificateRequest and sending Certificate.
>
> In most of the exchanges, we expect there to be an answer that is
> immediately available, so that
What makes this case interesting is the non-machine time that might exist
between receiving CertificateRequest and sending Certificate.
In most of the exchanges, we expect there to be an answer that is immediately
available, so that the implicit ACK works. Here we have to recognize that ACK
The TLS virtual interim will take place on 2020-04-27 19:00 - 21:00 UTC.
You can find more information on the IETF upcoming meeting page [1].
The chairs are looking for volunteers for notetaker and jabber scribe.
Please let us know if you will be able to help with these tasks.
[1]
In preparation for next week's virtual interim session on ECHO, I'd like to
draw your attention to the following issues and PRs we'll be discussing.
First, there's a PR up for padding
[https://github.com/tlswg/draft-ietf-tls-esni/pull/209]. This PR describes a
padding algorithm for clients
Just one comment.
On 23/04/2020, 00:54, "Martin Thomson" wrote:
> But Hanno's proposal is a terrible thing to have to implement. You
> have to assume that there is some way to recover which CID to use in
> decrypting any record. You might save some datagram-local state, but
> that's awkward.
Hi Chris,
Thanks for your reply. No, the PR does not address the issue described below,
because it keeps the use of a single kind of ACK for the two different purposes
(a) retransmission requests [optional] and (b) acknowledgement of completion
[mandatory]. However, it clearly describes this
On Thu, Apr 23, 2020, at 18:11, Hanno Becker wrote:
> You criticize that an implicit CID which is still included in the AAD
> requires state on the receiver when processing multiple records within
> a single datagram, which is true. I'm saying that the same holds for
> the PR 143 which adds the
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 to saying MUST
NOT omit.
On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote:
> > But
Hi Martin,
On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote:
> > But Hanno's proposal is a terrible thing to have to implement. You
> have to assume that there is some way to recover which CID to use in
> decrypting any record. You might save some datagram-local state, but
> that's awkward.
Hey,
Thanks for joining in, Martin and Chris.
> But Hanno's proposal is a terrible thing to have to implement. You have to
> assume that there is some way to recover which CID to use in decrypting any
> record. You might save some datagram-local state, but that's awkward.
> Stacks that
> -Original Message-
> From: TLS On Behalf Of Christopher Wood
> Sent: Tuesday, April 21, 2020 9:57 PM
> To: TLS@ietf.org
> Subject: [EXTERNAL] Re: [TLS] Comments on draft-ietf-tls-external-psk-
> importer-04
>
> Thanks for the feedback, Scott! Please see inline below.
>
> On Tue, Apr 21,
> -Original Message-
> From: TLS On Behalf Of Christopher Wood
> Sent: Wednesday, April 22, 2020 1:10 PM
> To: TLS@ietf.org
> Subject: [EXTERNAL] Re: [TLS] Comments on draft-dt-tls-external-psk-
> guidance-01
>
> Thanks for the feedback, Scott. Please see inline below.
>
> On Mon, Apr 20,
On Sat, Nov 23, 2019 at 05:32:36PM +0100, Karthik Bhargavan wrote:
> This is a bit of a shameless plug, but I think it is important to cite papers
> that show that the use of weak hash functions for TLS signatures is actually
> exploitable.
>
> As far as I know, the last round of deprecating
On Sun, Nov 24, 2019 at 11:27:26AM -0500, David Benjamin wrote:
> On Sat, Nov 23, 2019 at 8:40 AM Ilari Liusvaara
> wrote:
>
> > On Fri, Nov 22, 2019 at 08:18:47PM +0100, Hubert Kario wrote:
> > > On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote:
> > > > On Fri, Nov 22, 2019 at
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
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 to saying
> MUST NOT omit.
>
Hi Ekr,
Do you see some simplifications resulting from this?
On first thought I'd think that since implementations are already able to
handle implicit
ACKs, it doesn't come at extra cost to allow their use for post-HS client-auth,
too.
In contrast, it seems that if the client's Certificate
I don't feel strongly about it, and not changing anything is certainly
easier. It just felt out of place and I wanted to flag it.
-Ekr
On Thu, Apr 23, 2020 at 2:23 PM Hanno Becker wrote:
> Hi Ekr,
>
> Do you see some simplifications resulting from this?
>
> On first thought I'd think that
19 matches
Mail list logo
