I support adopting this draft.
On Tue, Nov 10, 2020 at 5:38 PM Ryan Sleevi wrote:
> On Tue, Nov 10, 2020 at 5:29 PM Victor Vasiliev 40google@dmarc.ietf.org> wrote:
>
>> On Mon, Nov 9, 2020 at 11:51 PM Martin Thomson wrote:
>>
>>> I've no objection to adopting this, though I will note that
On Tue, Nov 10, 2020 at 5:29 PM Victor Vasiliev wrote:
> On Mon, Nov 9, 2020 at 11:51 PM Martin Thomson wrote:
>
>> I've no objection to adopting this, though I will note that it is likely
>> of minimal use in the browser context due to the move to isolated storage
>> (which includes tickets).
On Wed, Nov 11, 2020, at 09:28, Victor Vasiliev wrote:
> > Thus, the draft needs to include privacy considerations, particularly
> > regarding cross-origin tracking. I am also of the opinion that it should
> > use flags, but that would depend on changes to the flags draft.
>
> I considered that
Hiya,
On 10/11/2020 22:27, Christopher Patton wrote:
Hi list,
In case the server sends a HelloRetryRequest (HRR) the client generates a
fresh ECH extension, including generating a fresh HPKE context and
corresponding encapsulated key. The following PR changes the spec so that
the HPKE context
Hi list,
In case the server sends a HelloRetryRequest (HRR) the client generates a
fresh ECH extension, including generating a fresh HPKE context and
corresponding encapsulated key. The following PR changes the spec so that
the HPKE context generated for the first ECH extension is reused to comput
On Tue, Nov 10, 2020, at 22:05, Stephen Farrell wrote:
> I'd be more in the "not yet" bracket for this. As Martin
> mentions this'd seem to create a possibly attractive way
> to do more tracking, so I think we ought try understand
> how that might fit into the wider set of new things (e.g.
> the HT
On Tue, Nov 10, 2020 at 10:41 PM Yaron Sheffer wrote:
>
> Hi,
>
> We are now revising RFC 7525 for the new world, and in general we are
> following this draft. So, MUST NOT negotiate TLS 1.0 and 1.1. This brought up
> the question of SCSV, which was new when RFC 7525 was published but has since
On Tue, Nov 10, 2020, at 9:35 AM, Benjamin Kaduk wrote:
> Hi Chris, all,
>
> This all sounds fine. I'm happy to approve a manual posting during the
> blackout period if we want to get this into IETF LC right away, though it's
> probably fine to just wait for submissions to reopen, too.
Let's jus
On Tue, 10 Nov 2020 20:40:57 +0200
Yaron Sheffer wrote:
> I think marking the “oldversions” draft as “obsoletes RFC 7507
> (SCSV)” is not great from an ecosystem point of view. People will
> interpret it as “no need to implement SCSV in new code, no need to
> expose it as a configuration option i
Hi,
We are now revising RFC 7525 for the new world, and in general we are following
this draft. So, MUST NOT negotiate TLS 1.0 and 1.1. This brought up the
question of SCSV, which was new when RFC 7525 was published but has since been
widely implemented/deployed.
I think marking the “oldversio
Hi Chris, all,
This all sounds fine. I'm happy to approve a manual posting during the
blackout period if we want to get this into IETF LC right away, though it's
probably fine to just wait for submissions to reopen, too.
Thanks,
Ben
On Thu, Nov 05, 2020 at 05:38:22AM -0800, Christopher Wood wr
On 10/11/2020 16:35, Sean Turner wrote:
Sorry for any confusion introduced as a result of this typo. DTLS 1.0
is RFC4347 not RFC 6347; RFC 6347 is DTLS 1.2.
Ah, mea-culpa then (even if someone else suggested
the change I should've spotted that;-). I'll look
back at the script algorithm in any
> On Nov 10, 2020, at 05:21, tom petch wrote:
>
> I am confused about the treatment here of DTLS.
>
> The Abstract seems clear about the proposed action for TLS but then the
> second paragraph has
> " This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347)"
>
> Mmmm, really?
On 10/11/2020 11:30, tom petch wrote:
Perhaps a second look at the algorithm
to work out why these got missed to get a fix on how many more there may be.
Sure, that's reasonable. (Mightn't be today.)
Cheers,
S.
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_si
On 10/11/2020 11:18, Stephen Farrell wrote:
Hiya,
On 10/11/2020 10:21, tom petch wrote:
I am confused about the treatment here of DTLS.
The Abstract seems clear about the proposed action for TLS but then
the second paragraph has
" This document also deprecates Datagram TLS (DTLS) version 1.0
Hiya,
On 10/11/2020 10:21, tom petch wrote:
I am confused about the treatment here of DTLS.
The Abstract seems clear about the proposed action for TLS but then the
second paragraph has
" This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347)"
Mmmm, really?
Sorry, I don't
Hiya,
On 10/11/2020 03:44, Joseph Salowey wrote:
Based on interest and support expressed at IETF 108, this email starts the
call for adoption of draft-vvv-tls-cross-sni-resumption. The draft can be
found here:
https://tools.ietf.org/html/draft-vvv-tls-cross-sni-resumption-00
This adopti
I am confused about the treatment here of DTLS.
The Abstract seems clear about the proposed action for TLS but then the
second paragraph has
" This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347)"
Mmmm, really?
There is a list of current RFC that Normatively reference the d
18 matches
Mail list logo
