Hiya,
On 9/25/24 00:07, David Benjamin wrote:
Ah, I see. I don't think "supported" vs "preferred" captures this because
"preferred" in the context of TLS usually isn't a binary property but a
preference order. But I agree there is some ambiguity over what to list if
you've got a couple differen
On Tue, Sep 24, 2024, at 16:11, David Benjamin wrote:
> I should add, another reason to call it tls-supported-groups is that
> this is essentially what the server would have put in the
> supported_groups extension, if negotiation order in TLS were inverted.
> Since TLS already saw fit[*] to name
On Tue, Sep 24, 2024 at 5:07 PM Stephen Farrell
wrote:
> >
> > Could you elaborate on how a long list could result in a failure or add
> > complexity?
>
> Again, I'll try:-)
>
> Let's say we have targets T1 and T2. And server instances S1, S2
> where T1 is served by both S1 and S2 but T2 only by
Please let the list know by 8 October 2023 if you support this “early"
> allocation.
>
I do.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
Could you clarify what you mean by supported vs preferred? I'm not sure I
follow what the difference is, in the context of a TLS implementation.
The intention is that you list all the NamedGroups you support, in order of
decreasing preference. That gives the client enough information to make a
rea
Hiya,
On 9/24/24 23:36, David Benjamin wrote:
Could you clarify what you mean by supported vs preferred? I'm not sure I
follow what the difference is, in the context of a TLS implementation.
I can try:-)
The intention is that you list all the NamedGroups you support, in order of
decreasing
On Tue, Sep 24, 2024, at 09:35, David Benjamin wrote:
> On Tue, Sep 24, 2024, 12:12 Martin Thomson wrote:
>> No DTLS implementation should treat unauthenticated packets as being fatal.
>> Though perhaps that could be true prior to completing the handshake, the
>> reasons for dying should stil
Once negotiated, the record size limit applies to all records; it
applies at the record layer. Handshake messages can span multiple
records.
On Mon, Sep 23, 2024 at 7:05 PM 崔久峰 wrote:
>
> After reading the Record Size Limit Extension for TLS RFC 8449, I found out
> that record_size_limit has re
Martin Thomson writes:
>Once negotiated, the record size limit applies to all records; it applies at
>the record layer. Handshake messages can span multiple records.
Just out of interest, does anything actually use this? max_fragment_length
seemed to be universally ignored, and then record_siz
Hiya,
I read the draft again just now. ISTM overall a fine idea.
I think the current draft is a bit ambiguous as to whether
the SvcParamKey reflects preferred or supported groups. It
may be better to resolve that before allocating a codepoint.
However, if the DEs considered a possible later ch
Ah, I see. I don't think "supported" vs "preferred" captures this because
"preferred" in the context of TLS usually isn't a binary property but a
preference order. But I agree there is some ambiguity over what to list if
you've got a couple different values.
I think, other than potentially changin
I should add, another reason to call it tls-supported-groups is that this
is essentially what the server would have put in the supported_groups
extension, if negotiation order in TLS were inverted. Since TLS already saw
fit[*] to name this concept supported_groups, I think that's a fine name
for th
I hate to add to the pile of issues, but we also have to figure out what to do
with the outstanding DTLS 1.2 errata as some might still impact DTLS 1.2; see
https://www.rfc-editor.org/errata_search.php?rfc=6347&rec_status=15&presentation=table
spt
> On Sep 23, 2024, at 20:06, Eric Rescorla wrot
Internet-Draft draft-ietf-tls-extended-key-update-00.txt is now available. It
is a work item of the Transport Layer Security (TLS) WG of the IETF.
Title: Extended Key Update for Transport Layer Security (TLS) 1.3
Authors: Hannes Tschofenig
Michael Tüxen
Tirumaleswar
On Thu, Sep 12, 2024, at 13:31, David Benjamin wrote:
> 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all)
> implementation receives an ACK record for whatever reason, what
> happens? This decision we don't get to change. Rather, it is a design
> constraint. Both OpenSSL and BoringSSL tr
> The point of this consensus call is to determine whether you think this I-D
> is stable enough to request a code point in the Expert Review range [1].
> Please let the list know by 8 October 2023 if you support this “early"
> allocation.
Yes.
___
Hi! I asked Thomas to submit this version because the -11 version was going to
expire on 3 October. We are waiting to send this I-D to our AD (Paul) until
after it gets FATT review, but, we haven’t gotten the FATT “process” squared
away just yet; see [0] about a virtual interim meeting to revie
Hi! After discussions with the author (David Benjamin) of
draft-ietf-tls-key-share-prediction [0], I would like to determine whether
there is consensus to request an “early” * code point request for a
'tls-supported-group' entry in the Service Parameter Keys registry; see Section
5 of the I-D.
Internet-Draft draft-ietf-tls-dtls-rrc-12.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.
Title: Return Routability Check for DTLS 1.2 and DTLS 1.3
Authors: Hannes Tschofenig
Achim Kraus
Thomas Fossati
Name:draft-
On Tue, Sep 24, 2024, 12:12 Martin Thomson wrote:
> On Thu, Sep 12, 2024, at 13:31, David Benjamin wrote:
> > 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all)
> > implementation receives an ACK record for whatever reason, what
> > happens? This decision we don't get to change. Rather, i
On Tue, Sep 24, 2024, 12:35 David Benjamin wrote:
> On Tue, Sep 24, 2024, 12:12 Martin Thomson wrote:
>
>> On Thu, Sep 12, 2024, at 13:31, David Benjamin wrote:
>> > 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all)
>> > implementation receives an ACK record for whatever reason, what
>>
On Tue, Sep 24, 2024 at 8:33 AM Sean Turner wrote:
> I hate to add to the pile of issues, but we also have to figure out what
> to do with the outstanding DTLS 1.2 errata as some might still impact DTLS
> 1.2; see
>
> https://www.rfc-editor.org/errata_search.php?rfc=6347&rec_status=15&presentatio
On Tue, Sep 24, 2024, 13:03 Martin Thomson wrote:
>
>
> On Tue, Sep 24, 2024, at 09:35, David Benjamin wrote:
> > On Tue, Sep 24, 2024, 12:12 Martin Thomson wrote:
> >> No DTLS implementation should treat unauthenticated packets as being
> fatal. Though perhaps that could be true prior to compl
23 matches
Mail list logo
