Eric Rescorla writes:
>Well, I note that the text also says "or have had very little usage,"
When the Brainpool-with-TLS RFC was published, several implementers announced
that they'd added support within 24 hours of the RFC appearing (in some cases
determined by time zones).
I think that was th
On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni
wrote:
>
> c. Testing is not a good fit at this layer, all that's
>pinned is the ability to deliver the extension, after a
>previous connection delivered DANE TLSA records and a
>non-zero extension support
On Wednesday, 18 July 2018 10:52:08 CEST Peter Gutmann wrote:
> Eric Rescorla writes:
> >Well, I note that the text also says "or have had very little usage,"
>
> When the Brainpool-with-TLS RFC was published, several implementers
> announced that they'd added support within 24 hours of the RFC a
On Wed, Jul 18, 2018 at 4:55 AM Eric Rescorla wrote:
>
> To the extent to which this is true, it's an argument that one should be
> pinning at a different layer.
>
>
(I've mentioned this in private email to some of you, but for broader
input, I'm throwing it out on the list too.)
On the topic of
On Wed, 18 Jul 2018, Eric Rescorla wrote:
detailed response to concerns raised in the room on Monday
On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni wrote:
c. Testing is not a good fit at this layer, all that's
pinned is the ability to deliver the extension,
As I understand from the text, the Brainpool curves itself are not prohibited,
but the code points assigned to them. So, if people still want to use the
Brainpool curves in conformance with the standard, I would conclude that they
can request new code points. This would result in an IANA registr
Hey TLS WG,
In response to some of the list discussion since the last IETF, Owen and I
revised our TLS PAKE draft. In the current version, instead of binding to
a single PAKE (SPAKE2+), it defines a general container that can carry
messages for any PAKE that has the right shape. And we think tha
Hi Ilari, I suppose you mean that this condition violates the critical bit
semantics: "If the extension is marked critical, then the server MUST NOT offer
the certificate unless it offers a delegated credential as well."
Your suggesting adding a "must-use-DC" flag to the extension body? The
co
> This would result in an IANA registry with duplicated entries for brainpool
> curves: the old, now prohibited code points and the new assigned ones. Is
> this correct?
No. The request could ask for the existing reserved codepoints to be re-used.
___
>> This would result in an IANA registry with duplicated entries for brainpool
>> curves: the old, now prohibited code points and the new assigned ones. Is
>> this correct?
>No. The request could ask for the existing reserved codepoints to be re-used.
But note that the WG decision was to r
> This would result in an IANA registry with duplicated entries for brainpool
> curves: the old, now prohibited code points and the new assigned ones. Is
> this correct?
No. The request could ask for the existing reserved codepoints to be re-used.
No offense meant, but this does not make
>No offense meant, but this does not make sense. Code points were assigned,
>probably some apps were/are using them. Now those code points are to be
>invalidated, and new ones assigned instead?!
Perhaps I am confused.
Code points for pre-1.3 were assigned, and they are invalid for TLS 1.3.
> On Jul 18, 2018, at 13:42, Salz, Rich wrote:
>
> >No offense meant, but this does not make sense. Code points were assigned,
> >probably some apps were/are using them. Now those code points are to be
> >invalidated, and new ones assigned instead?!
>
> Perhaps I am confused.
Likelier that
Hi Viktor,
Thanks for writing up your thoughts; a couple notes inline:
On Tue, Jul 17, 2018 at 10:30:39PM -0400, Viktor Dukhovni wrote:
>
> Below I shall try to address a few of the concerns raised in writing.
> You can read just the high-level notes above my signature, diving
> into the corresp
I do not think you can change an extension syntax or semantic. It is three
tuple: extn ID, criticality flag, and value.
You can add the syntax and semantics within the extension value as to what
it means. That may not help those who do not understand the extension and
cannot process the val
A group met this afternoon to discuss the TLS DNSSEC document. I
want to thank the participants as I think it was a productive meeting.
Here
is chairs' summary of some of the important points of the discussion from
notes from the meeting. The second section outlines some behavior that
we need to
+1 for this work.
If you are one of those that think, as I did 20 years ago, that password
authentication is dying and practical replacements are just around the
corner, do not support this document. Otherwise, please do.
Asymmetric or augmented PAKE (aPAKE) protocols provide secure password
auth
On Wed, Jul 18, 2018 at 06:28:39PM -0400, Joseph Salowey wrote:
> THE NON-TLSA BEHAVIOR
> Consider the following TLSA record:
>
> - domain example.com
> - record for key K1
> - TTL of 3600s
>
> If I retrieved this record over DNS and then connected to example.com
> over TLS and it ga
On Wed, Jul 18, 2018 at 01:54:09AM -0700, Eric Rescorla wrote:
> On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni
> wrote:
> >
> > c. Testing is not a good fit at this layer, all that's
> >pinned is the ability to deliver the extension, after a
> >previous connectio
On Wed, Jul 18, 2018 at 08:41:59AM -0400, Shumon Huque 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 and I dis
20 matches
Mail list logo
