Hiya,
On 19/07/2021 22:43, David Benjamin wrote:
No. I'm saying there is a need for text around resumption and privacy,
whether or not we publish this draft. There is a copy of the text to
address it in both documents. The text applies equally well to both, thus I
am satisfied with how this
On Mon, Jul 19, 2021 at 5:32 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 19/07/2021 22:13, David Benjamin wrote:
> > I don't think that's an accurate characterization of what's going on. I
> at
> > least care about both optimization and privacy.
>
> Sure. We just disagree, I've no doubt you care
Hiya,
On 19/07/2021 22:13, David Benjamin wrote:
I don't think that's an accurate characterization of what's going on. I at
least care about both optimization and privacy.
Sure. We just disagree, I've no doubt you care about those.
We should apply
optimizations only where they do not
On Mon, Jul 19, 2021 at 4:20 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 19/07/2021 17:50, David Benjamin wrote:
> > Do you have other text in mind? There doesn't seem to be any other
> possible
> > answer here, since there is only one decision to make in resumption.
>
> There is a 3rd option:
Hiya,
On 19/07/2021 17:50, David Benjamin wrote:
Do you have other text in mind? There doesn't seem to be any other possible
answer here, since there is only one decision to make in resumption.
There is a 3rd option: don't standardise the flag. That'd be
my preference, but as I said maybe
Hubert Kario writes:
>It only doesn't matter if you don't want to verify the certificate...
>
>It's one thing to be able to be able to verify an RSA-PSS signature on TLS
>level, it's entirely another to be able to properly handle all the different
>RSA-PSS limitations when using it in SPKI in
On Mon, Jul 19, 2021 at 12:38 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 19/07/2021 17:35, David Benjamin wrote:
> > We need to*both* not add new tracking vectors*and* mitigate the
> existing
> > ones. Doing either one on its own is not useful. That means if the
> existing
> > mitigation for
Hiya,
On 19/07/2021 17:35, David Benjamin wrote:
We need to*both* not add new tracking vectors*and* mitigate the existing
ones. Doing either one on its own is not useful. That means if the existing
mitigation for the existing vector applies just as well to this new
feature, we have not added
On Mon, Jul 19, 2021 at 12:27 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 19/07/2021 17:17, David Benjamin wrote:
> > I'll add that, in the context of cross-domain tracking on the web, this
> > draft is a red herring. Remember that web pages have subresources. That
> > means looking at the
Hiya,
On 19/07/2021 17:17, David Benjamin wrote:
I'll add that, in the context of cross-domain tracking on the web, this
draft is a red herring. Remember that web pages have subresources. That
means looking at the destination domain isn't useful because two different
pages can embed a common
I'll add that, in the context of cross-domain tracking on the web, this
draft is a red herring. Remember that web pages have subresources. That
means looking at the destination domain isn't useful because two different
pages can embed a common destination domain. So the same concerns exist
with
Hiya,
On 19/07/2021 16:21, Ryan Sleevi wrote:
On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell
wrote:
I don't find the reference to [FETCH] explains how that
problem can be mitigated by browsers. (IIRC, adding that
was the result of earlier discussion of this point?)
I'm not sure I'm
On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell
wrote:
> I don't find the reference to [FETCH] explains how that
> problem can be mitigated by browsers. (IIRC, adding that
> was the result of earlier discussion of this point?)
>
I'm not sure I'm parsing this correctly.
Are you saying that you
On 7/19/2021 10:16 AM, Salz, Rich wrote:
I support publication.
https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Nit - which also applies to
On 19/07/2021 15:16, Salz, Rich wrote:
I support publication.
I don't, though I may be in the rough.
We did discuss this a bit earlier but from my POV this
adds a new vector for cross-domain tracking and we ought
be removing those, not adding them.
I don't find the reference to [FETCH]
I support publication.
> https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Mon, Jul 19, 2021, at 23:25, Hubert Kario wrote:
> That's because browsers don't have the code to handle RSA-PSS certificates.
Not ALL the code, but we only have one small piece left in Firefox. And we
have plans to address the final small piece. So maybe soon.
On Monday, 19 July 2021 14:06:41 CEST, Peter Gutmann wrote:
Ilari Liusvaara writes:
Actually, I think this is quite messy issue:
It certainly is.
Signature schemes 0x0403, 0x0503 and 0x0603 alias signature
algoritm 3 hash
4, 5 and 6. However, those two things are not the same, because
Ilari Liusvaara writes:
>Actually, I think this is quite messy issue:
It certainly is.
>Signature schemes 0x0403, 0x0503 and 0x0603 alias signature algoritm 3 hash
>4, 5 and 6. However, those two things are not the same, because the former
>have curve restriction, but the latter do not.
That
19 matches
Mail list logo
