>> Code points for pre-1.3 were assigned, and they are invalid for TLS 1.3.
>> Those “you should not send these for 1.3” could be re-used for TLS 1.3, if
>> that was desired.
>
> Yes this makes sense. And I think that they should, documented as something
> other than “Recommended”.
>
I still
SHOULD NOT would probably be fine. MUST NOT is too strong, and probably needs
revisiting.
Regards,
Uri
Sent from my iPhone
On Jul 19, 2018, at 06:32, Johannes Merkle wrote:
>>> Code points for pre-1.3 were assigned, and they are invalid for TLS 1.3.
>>> Those “you should not send these for
>I still don't get it. If the existing code points are re-used, the TLS 1.3
> standard is violated.
Right. So a document will have to be written that updates the RFC to use them.
Or, go for other codepoints.
Either way, I think it will be an uphill struggle to convince the WG, who would
Unfortunately, I haven’t had time to review the document, but +1 for
interesting problem, and +1 for anything Richard writes as a good starting
point, even if I haven’t read it.
-Tim
From: TLS On Behalf Of Hugo Krawczyk
Sent: Wednesday, July 18, 2018 7:13 PM
To: Richard Barnes
Cc:
Sub
On Wed, Jul 18, 2018 at 10:23:49PM -0500, Nico Williams wrote:
> > At yesterday's WG meeting, Sam Weiler suggested that the pinning
> > information could be conveyed via the DNS. That way you would not need new
> > holes/fields in the TLS extension. Paul said it doesn't work. But Willem
> > Toorop
Thanks both of you for the feedback.
I've revised the PR:
https://github.com/tlswg/tls-subcerts/pull/9
There's now a "strict" flag that, if set, requires the server to offer a DC..
In Sec. 6.1, I describe why I think this is sufficient. Let me know what you
think!
Best,
Chris
___
On Thu, Jul 19, 2018 at 12:16:18PM -0400, Viktor Dukhovni wrote:
> On Wed, Jul 18, 2018 at 10:23:49PM -0500, Nico Williams wrote:
> > > At yesterday's WG meeting, Sam Weiler suggested that the pinning
> > > information could be conveyed via the DNS. That way you would not need new
> > > holes/field
On Thu, Jul 19, 2018 at 07:04:31PM +, Patton,Christopher J wrote:
> Thanks both of you for the feedback.
>
>
> I've revised the PR:
>
> https://github.com/tlswg/tls-subcerts/pull/9
>
>
> There's now a "strict" flag that, if set, requires the server to
> offer a DC. In Sec. 6.1, I describe
So you think we need that the extension is marked critical if and only if the
strict flag is set? That wouldn't be ideal. Can you explain your thinking?
Which case presents a problem?
From: ilariliusva...@welho.com on behalf of Ilari
Liusvaara
Sent: Thursday,
On Thu, Jul 19, 2018 at 07:56:05PM +, Patton,Christopher J wrote:
> So you think we need that the extension is marked critical if and
> only if the strict flag is set? That wouldn't be ideal. Can you
> explain your thinking? Which case presents a problem?
There are two types of clients:
1) Cl
Suppose that strict delegation usage is required (strict=true). Is it valid for
the extension to be non-critical (crit=false)? No, because the server has to
serve a DC, even if the client doesn't request one. Thus, strict=true implies
that crit=true.
Now let's check the converse. Suppose that
Hi all,
As I mentioned at the mic today, there is a question that has been
raised about whether it's wise to reuse an existing (TLS 1.2) PSK
directly in the TLS 1.3 key ladder. At a high level, the reason why one
might want to restrict this is that the security proofs for TLS 1.3 rely
on the pre-
I strongly support this work.
Also, having made this mistake myself in the past: please make sure that
we have one fully specified PAKE in this document, and not only a
generic envelope. This will ensure that TLS libraries have at least one
working, and interoperable, PAKE,
Thanks,
Y
13 matches
Mail list logo
