[TLS] Artart early review of draft-ietf-tls-wkech-04

[Martin Thomson via Datatracker]

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.

The current design involves publishing information for a multitude of
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.

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.

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

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

Nits:

Titles are not sentences.  Lose the period.

S1, typo: ECHConflgList

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?

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

S3, typo: regularaly

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".

> 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.)

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?


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Artart last call review of draft-ietf-tls-external-psk-guidance-03

[Martin Thomson via Datatracker]

Reviewer: Martin Thomson
Review result: Ready with Issues

This document addresses some of the less obvious aspects of how pre-shared keys
can be used in TLS.  A lot of this advice isn't specific to TLS, but it is a
helpful document.  For someone who might be deploying a protocol that relies on
TLS - or might rely on it - the document is a useful resource.

My only concern overall, and it is a vague concern, so I don't think action is
needed, is that the document could probably use a little trimming.  There are
some parts of the document that are less useful than other parts.  For example,
the bit about who has the PSKs is great (one server, one client, don't swap
roles); but it is repeated a little across multiple sections.  The same applies
to a few of the other points.  It is probably not worth trying to edit the
document down so that each point is made just once, because it isn't that bad,
but a shorter document would be more impactful.

A specific concern is the somewhat offhand way that early data is treated.  The
only mention is in a throwaway: "primarily for the purposes of supporting TLS
connections with early data" buried in a bullet in Section 6.  This is a pretty
big topic and having absolutely no mention seems odd.  I do think that it needs
some treatment in the document.  When early data is used with an external PSK,
the only additional source of entropy that provides key diversity is the
client's random value, which puts a lot of weight on that value containing
sufficient entropy.  In this case, even if the PSK is good enough, the entropy
in the random is significant as it is what ensures traffic key diversity if the
PSK is reused.  Reusing a PSK for early data also likely leads to poor
anti-replay performance if the random is not good enough.

I have to apologize to the authors for missing this when it went through the
working group.  Fresh eyes and all that.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls