[TLS] Re: I-D Action: draft-ietf-tls-wkech-09.txt

[Stephen Farrell <[e-mail]>]

Hi Ted,

On 02/09/2025 15:40, Ted Hardie wrote:
> Hi Stephen,
> 
> I have what I hope is a small question about the IANA registration.  In the
> protocol description, the draft says:
> 
>     The JSON file at the well-known URI MUST contain an object with two
>     keys: "regeninterval", whose value is a number, and "endpoints" whose
>     value is an array of objects.  All other keys MUST be ignored.
> 
> In the IANA considerations for the new JSON Service Binding registry, you
> specify Standards Action is required to update the registry. 

Ah. I think Standards Action was Ben's choice, or else, apologies to
Ben, and I just forget why we said that;-)

> It seems to
> me that you actually need something a bit narrower, a Standards Action that
> updates or obsoletes this RFC, since other actions wouldn't eliminate the
> "MUST be ignored." requirement.

That's logical.

> My IANAbis chair hat isn't on for this question, but it does cause me to
> think about what folks mean by Standards Action in a case like this; do the
> authors assume Standards Action is sufficient, because that process would
> check to make sure that the new standard didn't need to make an update to
> this RFC?

Yes, I would make that assumption, and it may be worth stating
in the document I guess?

Or... we could consider "loosening" the registry update rule to
expert review with guidance to the expert that they should think
when adding things to that registry as the current setup means
they'll be ignored by existing implementations. (So, not much
point adding negative-things/constraints that need to be honoured
I guess.)

I created a GH issue for this. [1]

Thanks,
S.

[1] https://github.com/sftcd/wkesni/issues/57

> 
> Thanks,
> 
> Ted Hardie
> 
> 
> On Tue, Sep 2, 2025 at 2:40 PM Stephen Farrell <[e-mail]>
> wrote:
> 
>>
>> Hiya,
>>
>> We made a bunch of editorial changes after the comments
>> received at IETF-123 with which the commenters seem ok,
>> so the authors would like to ask if the chairs think this
>> is ready for WGLC. (We understand the plan is to park it
>> after that awaiting more implementation experience which
>> is fine.)
>>
>> There are no outstanding issues or PRs on the git repo. [1]
>>
>> Cheers,
>> S.
>>
>> [1] https://github.com/sftcd/wkesni
>>
>> On 02/09/2025 14:30, [e-mail] wrote:
>>> Internet-Draft draft-ietf-tls-wkech-09.txt is now available. It is a
>> work item
>>> of the Transport Layer Security (TLS) WG of the IETF.
>>>
>>>      Title:   A well-known URI for publishing service parameters
>>>      Authors: Stephen Farrell
>>>               Rich Salz
>>>               Benjamin Schwartz
>>>      Name:    draft-ietf-tls-wkech-09.txt
>>>      Pages:   18
>>>      Dates:   2025-09-02
>>>
>>> Abstract:
>>>
>>>      We define a well-known URI at which an HTTP origin can inform an
>>>      authoritative DNS server, or other interested parties, about its
>>>      Service Bindings.  Service binding data can include Encrypted
>>>      ClientHello (ECH) configurations, that may change frequently.  This
>>>      allows the origin, in collaboration with DNS infrastructure elements,
>>>      to publish and rotate its own ECH keys.  Other service bindng data
>>>      such as information about TLS supported groups is unlikely to change
>>>      quickly, but the origin is much more likely to have accurate
>>>      information when changes do occur.  Service data published via this
>>>      mechanism is typically available via an HTTPS or SVCB resource
>>>      record.
>>>
>>> The IETF datatracker status page for this Internet-Draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-wkech/
>>>
>>> There is also an HTMLized version available at:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-wkech-09
>>>
>>> A diff from the previous version is available at:
>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-wkech-09
>>>
>>> Internet-Drafts are also available by rsync at:
>>> rsync.ietf.org::internet-drafts
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> TLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>