Re: [art] Artart early review of draft-ietf-tls-wkech-04

[Stephen Farrell <[e-mail]>]

Hi Martin,

Thanks for the review. (More such are v. welcome esp as ECH is
now past WGLC.)

On 02/04/2024 00:40, Martin Thomson via Datatracker wrote:
> Reviewer: Martin Thomson
> Review result: Not Ready
> 
> This document describes how an HTTP origin can publish information about its
> ECH configuration so that other nodes can aid it in setting up the DNS records
> necessary to run DNS.
> 
> Issues:
> 
> Most of the document talks about having the back-end servers produce content
> for the well-known resource, but there is mention of other servers being
> involved as well.  ECH depends on having shared configuration at the
> client-facing side for servers, so any configuration process should probably
> involve something different.  That is, having each server produce information
> about its own (perceived) configuration, with the zone factory being
> responsible for synthesizing the information from each into a coherent whole.
> 
> In that design, a back-end server would indicate that they are using a shared
> client-facing server, and point to it.  The client-facing server would supply
> its ECH configuration (which might be different for different back-end
> servers).  There are cases where a client-facing server might be able to
> produce the content for a back-end server, so that a single resource could make
> sense. That might lead to the design we see, but that is not obviously correct
> for all aspects of the design.

I'm not really sure how to interpret the above tbh. Was that intended
as a summary of the draft or as a synopsis of the problem space?

> The current design involves publishing information for a multitude of

Well, s/involves/allows/ is maybe more accurate but that's a nit-pick...

> ECHConfigList values and multiple target names (and ports).  It is not obvious
> that it is safe to have one origin speak for multiple others in this way or
> what conditions might be necessary to have that happen safely.  If there is a
> validation process involved, that might work.  The process in S6 is too loose
> for me to be confident in that being sufficient.

That's fair. What's defined now supports (hourly) ECH key rotation for
the set of test servers I have on different ports of the same VM. In
that case, there's a different http server implementation listening on
each port, which I guess would be an extremely unlikely production
configuration, but OTOH, it seems right to be able to support that odd
case. And I think if we can support that odd case, then we'll also be
ok for more likely production cases.

> The design for publishing alias records is something I cannot decipher at all.
> There's a description of the field, but no real supporting material for that.

Also fair. Will add more description of that and we can see if it makes
more sense then. I'm a bit unsure what to add right now though given
it's been hard to test aliasMode - does anyone know if browsers now
support that (with ECH)? (Been a while since I tried that, but will
do some more testing as we produce a -05 draft.)

> The different deployment options need to be more clearly articulated in support
> of different modes of use, along with any validation that is needed.

Happy to document the validation more, but the basic idea is that the
ZF checks ECH works, and if it does, then the ZF is ok to re-publish.
If anyone has ideas on other kinds of checks that'd be sensible, be
happy to consider incorporating those.

> 
> It might be the case that the design is fundamentally sound, but it isn't clear
> to me that this is true.

I'm happy to try convince you over time:-)

More concretely, I can try add text to the security considerations
that argues that the design meets some security goal(s) and we can
discuss that text as we go forward.

> 
> Nits:
> 
> Titles are not sentences.  Lose the period.

Where? (Sorry, not sure, but the RFC editor will fix anyway
so no worries.)

> 
> S1, typo: ECHConflgList

Fixed.

> Use of the term "front-end" and "back-end" is likely confusing for some
> consumers of this specification.  Front-end overwhelmingly refers to the
> development of web-facing content, whereas back-end refers to the development
> of servers and services.  Why not use client-facing as the ECH specification
> does?

I'll give it a shot, but have always found that terminology a
bit confusing. I could also add a diagram too I guess, which
may help the reader a bit.

> 
> S3, please avoid using things like "cronjob".  Periodic is fine and doesn't
> presume the use of a particular tool.

It's an example, but a fairly well known one. Will look at the wording
though.

> 
> S3, typo: regularaly

Fixed.

> 
> S4:
> 
>> The well-known URI defined here MUST be an https URL and therefore the ZF
> verifies the correct BE is being accessed. If no new ECH value resulting
> "works," then the zone factory SHOULD NOT modify the zone.
> 
> This is two very different concepts in the one paragraph.  The first is about
> authenticating the content at the .w-k resource.  The second is about
> validating it.  There is no segue between the two.  Maybe you could say "The ZF
> MUST validate any ECHConfig that it obtains before publishing information to
> the DNS zone."
> 
> Also, avoid "scare quotes" and say what you mean by "works".

Ack. Will split/re-word.

>> Note that a consequence of the URL above is that back-ends that wish to use
> different ECH settings are very likely to have to use different "DocRoot"
> settings.
> 
> What is DocRoot?  (Really. I don't know what this means.)

The directory where a web server stores static resources on disk.
E.g. if the DocRoot is "/www/" then there'd likely be a file like
"/www/index.html" that'd be what you get when you access the
web site. I think that's an apache term, but dunno if there's a
good generic term for it. (We could maybe just delete the sentence
as it was just noting a change in -04 compared to earlier versions.)

> More generally, I would prefer a use case or goal-motivated structure to the
> document than a format-based one.  That is, consider answering some questions:
> what information would a back-end server produce?  what would a front-end
> produce?  what would you include (and validate) if you wanted to have aliases?

That's also fair. The draft as of now is v. terse, but I'll work on
some text for the above.

Given all the above, it's probably fine if you wait 'till there's a
-05 done before we chat more, (assuming you have time), but happy to
discuss via email in the meantime too of course.

Cheers and thanks again,
S.

> 
>