I am fine with putting a more inclusive name on the existing range.
Russ
> On Mar 28, 2024, at 6:04 PM, David Benjamin wrote:
>
> I don't believe we need a separate range, just to unmark the elliptic curve
> range. TLS does not usually ascribe meaning to ranges of codepoints because
> TLS
> KEMs are not "key agreement" algorithms as suggested by this draft name.
In a key agreement algorithm, both parties contribute to the shared
secret. With a KEM, only one party generates the the shared secreat value.
This is not generally accurate with the KEM schemes under consideration for
Hi! I am going to kick off some early reviews from the DNS and HTTP
directorates to see if we get anything back.
spt
> On Mar 27, 2024, at 16:37, internet-dra...@ietf.org wrote:
>
> Internet-Draft draft-ietf-tls-svcb-ech-01.txt is now available. It is a work
> item of the Transport Layer
For those who are unfamiliar, the "pitch" of OCB mode is that it's fast
everywhere: on servers, desktops, smartphones, and low-power IoT devices
with some sort of hardware-accelerated block cipher, whereas currently GCM
is popular on higher-power devices like servers/desktops/smartphones
whereas
I'm not telling you that you have to require DNSSEC. I'm saying the
document is incomplete if you don't talk about how it relates to DNSSEC. I
think EKR got the point, so maybe go with his approach?
On Fri, Mar 29, 2024 at 6:27 PM Rob Sayre wrote:
> It's a policy choice, though, right? I think
On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker
wrote:
> Reviewer: Ted Lemon
> Review result: Almost Ready
>
> This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01.
>
> Section 4.1 advises disabling fallback, but does not talk about DNSSEC,
> which
> is surprising given that
On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker
wrote:
>
> I don't think it's reasonable to specify the privacy properties of SVCB and
> /not/ talk about DNSSEC validation.
>
Could you explain more about this part? I think DNSSEC doesn't add much
here, unless you want to accept
On Fri, Mar 29, 2024 at 1:42 PM Deirdre Connolly
wrote:
> > KEMs are not "key agreement" algorithms as suggested by this draft
> name. In a key agreement algorithm, both parties contribute to the shared
> secret. With a KEM, only one party generates the the shared secreat value.
>
> This is
It's a policy choice, though, right? I think ekr hinted at this issue as
well.
It's that one might also view requests that reveal the SNI as insecure. If
that's the case, DNSSEC doesn't help. There will certainly be a transition
period where that will be impractical for many servers. I think
I don't think it relates to DNSSEC. You can fail at DNS (DNSSEC failure) or
you can fail during ECH (unless you want to use non-ECH, which is not ECH,
and not part of this draft).
It makes sense to me: one can reject a request unless the requirements
embedded in the SVCB are met (the server
Reviewer: Ted Lemon
Review result: Almost Ready
This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01.
Section 4.1 advises disabling fallback, but does not talk about DNSSEC, which
is surprising given that the draft proposes privacy properties for SVCB
responses containing ECH data. I
It looks like if you can't get the SCVB you're going to fail insecure, so
being able to use DNSSEC to prevent that for signed domains seems
worthwhile.
On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre wrote:
> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
> nore...@ietf.org> wrote:
>
>>
That seems okay. Would be good to document in the security considerations.
On Fri, Mar 29, 2024 at 4:41 PM Eric Rescorla wrote:
>
>
> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
> nore...@ietf.org> wrote:
>
>> Reviewer: Ted Lemon
>> Review result: Almost Ready
>>
>> This is a
Okay, I think I see the disconnect, maybe. The issue I'm pointing to is
that you may or may not be doing DNSSEC validation. And you may or may not
be /able/ to do DNSSEC validation if the infrastructure breaks it
accidentally or deliberately.
The document says: "The SVCB-optional client behavior
Yes, that fully addresses my concern. Thanks!
Op vr 29 mrt 2024 om 22:54 schreef Eric Rescorla
>
> Hi Ted,
>
> Doesn't this section of RFC 9460 address this case and say what you are
> recommending:
>
> https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1
>
> -Ekr
>
>
>
> On Fri, Mar 29,
Hi Ted,
Doesn't this section of RFC 9460 address this case and say what you are
recommending:
https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1
-Ekr
On Fri, Mar 29, 2024 at 6:49 PM Ted Lemon wrote:
> Okay, I think I see the disconnect, maybe. The issue I'm pointing to is
> that you
16 matches
Mail list logo
