Hiya,
On 21/06/2024 17:26, Sean Turner wrote:
Gentle reminder this WGLC is still ongoing.
I (strongly:-) support publication. I do have comments but really
am ok if those are ignored.
- section 3 has a MUST for checking all IP addresses are for servers
that have access to the relevant ECH private key material. We go into
some more detail on how to do that in [1] so perhaps some of that
text ought be here, or (given the best HOWTO may change) that could
be via a reference to [1]. OTOH, that'd maybe be a normative ref
so could delay things, so not sure how best to proceed. (See also
the "bind" comment at the end.)
- A particular case of the above is if an ECHConfigList has more
than one ECHConfig (e.g. for different algs). I'm not sure if the
text here implies that all public values must "work" or if it
means that at least one public value must "work." (In publication
code I've written I check all public keys and only publish if all
public keys are ok, but one could do otherwise and not suffer
disaster:-)
- I'm not clear if section 3 implies a server has to check that
all relevant A/AAAA and ipv[46]hint values are present and
correct before publication. (Test publication code I've done
currently ignores hints at publication time, and just checks
one of A/AAAA works, but I'd be ok with being more picky.)
- I think it'd be better (but not necessary) if section 3 had some
guidance on when >1 HTTPS RRdata value is reasonable or to be
expected for ECH-specific reasons. (Basically, if one has >1
CDN I guess?)
- I wonder if there's a need to consider the new happy eyeballs
stuff [2] before declaring victory here. I've no strong opinion but
this and [2] probably should at least not contradict one another.
(I don't know if that's been checked.)
- Does 4.1 correspond to what browsers do now with ECH? It's
not clear to me that it does, but I'm not sure. (I'm currently
writing a test generator to figure that out but it'll be some
weeks before I could answer the question myself.)
- 4.2 implies but does not say that parts of the ech= value that
affect the outer CH need to be encoded as extensions within the
ECHConfigList, or else are at the whim of the client code. That's
probably ok, but worth a bit of thought. (Personally, I'd prefer
we disparage extensions within ECHConfigList values but I think
I've lost that argument before:-)
- 4.3 has a MUST NOT for clients - do we need to say that that
means normal clients and not the special-case client that is
needed to do checks before publication?
- section 5 says: "Origins that publish an "ech" SvcParam in their
HTTPS record SHOULD also publish an HTTPS record with the "ech"
SvcParam for every alt-authority offered in its Alt-Svc Field
Values. Otherwise, clients might reveal the name of the server
in an unencrypted ClientHello to an alt-authority." I think some
examples of that would really help. More generally some examples
would be good to add as an appendix.
- I'd like to (yet again:-) suggest that defining a PEM format for
ECH stuff would be worthwhile, and could be done as an appendix of
this document. (I.e. include [3] as an appendix.) When I suggested
this before, there was some opposition so it;s ok if people still
don't want that, but IMO it'd be good were that defined somewhere.
- Finally, I've been playing with bind a bit to see what it allows
be published. See below for what's published for one name right
now (I may delete that or it might still work when you read this,
apologies if the latter applies:-)
$ dig +short https dodgy.test.defo.ie
1 . ech=eHl6dwo=
1 . ech
1 . ech=YWJjCg==
10000 . ech=dG90YWwtY3JhcAo=
1 . ech=Cg==
Given that the onus should be on ECH aware clients to reject such
dodgy stuff, perhaps we'd be better off to just say that publishers
MUST check the presentation syntax is empty or valid base64 and
SHOULD be a base64 encoded ECHConfigList? Then we could leave all
the details of checks before publication to [1] which may be a
better approach.
Again though, I'm fine that this be published as-is and prefer
that to spending loads of time arguing, so do feel free to ignore
any of the above,
Cheers,
S.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-tls-wkech
[2] https://datatracker.ietf.org/doc/draft-pauly-v6ops-happy-eyeballs-v3/
[3] https://datatracker.ietf.org/doc/draft-farrell-tls-pemesni/
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
