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 Hanno'
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. Sta
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
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. S
> -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 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 8:35
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 MD5
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 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 mes
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 sin
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 tha
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 disc
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
mi
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
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] https://datatra
17 matches
Mail list logo
