Draft: draft-ietf-tls-esni

Commentary: This combines and , requiring that validation of publicname happen somewhere _ , providing a reference parser ( if one does not exist ) , and allowing it to happen when parsing ECHConfig . , cc 
 The  for a label in a DNS name is 63 octets though is n't it ? 
 Yeah , but RFC6066 has no similar requirements ( that I can tell ) , so I do n't see we need to impose anything new here . Maybe I 'm missing something ? And if so , can you please propose text ? 
 Fair ask:- ) I guess the public_name mostly has to go in a cert SAN so would it help to use or refer to rfc5280 text ? The most relevant bit there seems to be : When the subjectAltName extension contains a domain name system label , the domain name MUST be stored in the dNSName ( an IA5String ) . The name MUST be in the " preferred name syntax " , as specified by Section 3.5 of [ RFC1034 ] and as modified by Section 2.1 of [ RFC1123 ] . Note that while uppercase and lowercase letters are allowed in domain names , no significance is attached to the case . In addition , while the string " " is a legal domain name , subjectAltName extensions with a dNSName of " " MUST NOT be used . ( That text is near [ 1 ] ) . That said , that " " is a legal domain name surprises me ( and I 'm a co - author of 5280 ! ) BTW , I 'm fine that that all gets fixed later if that 's better . S. [ 1 ] 
 Sounds good -- I dropped an OPEN ISSUE to note this for later . would you have cycles to take that issue and propose a PR to address it ? 
 Sneaky eh:- ) Sure , I can look at it this week but do n't wait on me . S 
 Yeah , there 's no rush here , I think . This seems like a smaller issue to resolve at some point . 
 For at least command line clients ( e.g. curl ) and perhaps for censorship circumvention tools it makes sense to allow the outer SNI to contain nothing or something that is not the publicname from the SVCB RR . It 's possible that any tool that acquires an ECHConfig from a non - DNS source would benefit from that option too . The offending ( for me:- ) text is in section 6.1 , 2nd list , bullet 7 where it says : ' The value of ECHConfig.contents.publicname MUST be placed in the " server_name " extension . ' There may be clients that do need the above . I 'm not sure how to chacterise those in a short phrase , but that 's likely possible . At the IETF-110 TLS session mention was made of clients that need to fallback but I 'm not sure what reference would be correct for that if e.g. we appended something like " clients that need to be able to fallback . [ ref ] " 
 Censorship circumvention is n't one of the stated goals of ECH . Even if an ECHConfig is acquired from a non - DNS source , it still has the ECHConfig.contents.publicname field , which , as specified in 6.1.3.3 , is necessary because : " The client MUST verify that the certificate is valid for ECHConfig.contents.publicname . If invalid , it MUST abort the connection with the appropriate alert . " 
 I believe we should keep this as - is .  is for the server 's benefit and the client has no way of knowing whether it will be needed . 
 +1 -- for robustness reasons , I believe we should keep this as - is . 
 I also found this requirement odd . Is it really necessary with the changes to config_id in draft -10 ? If someone could explain why this should be mandatory , that would be fine . I just do n't understand the requirement . 
 When there is a mismatch between DNS and the server configuration , the server will handshake with the outer ClientHello . The expectation when that happens is that the connection is authenticated for the public name , which gives an authenticated recovery signal . That means the server needs to , e.g. , select a certificate that covers the public name . Thus , the outer SNI selection . 
 OK , and a server that did n't need the outer SNI name would be identifiable by IP address anyway . Makes sense . 
 Sure - the right MUST be valid for the client to act upon failed ECH . I do n't see that that implies that the ech.public_name MUST be sent though .    , I understand the sensitivities there but nor are we forced to make life harder for those who develop such applications . ( Separately , I do n't recall there being any consensus call related to whether or not that is or is not a goal . ) A requirement for the client to verify the vs. the presented cert does not need to involve the publicname . I 'm fine that the client MUST ( as always ) verify the presented cert vs. the if ECH did n't work . I 'd also be fine with a SHOULD send here , or with a " MUST default to send publicname in " but an absolute MUST is not necessary afaics . The issue for me is for a generic library - in that case being able to override the public_name seems like it may sometimes be useful and since there 's no need to require library developers to enforce the MUST , it 's a bad plan I think . Cheers , S. 
 Hiya , Not convinced . For a web browser talking to a web server given a sensible set of DNS RRs , I do agree with you . For any random TLS client / server pair , I 'm not yet convinced . Hence I still consider an absolute MUST OTT / wrong . S. 
 One oddity of this requirement is that it presents a GREASE distinguisher when the client is connecting to an IP address with no server name . In the GREASE case , the ClientHelloOuter.servername is absent because . In the real - ECH case , ClientHelloOuter.servername is present and contains ECHConfig.public_name . However , why use ECH at all if the IP address uniquely identifies the desired service ? I think I support keeping the requirement for the sake of the fallback / retry mechanism . Was there some other scenario you 're thinking of ? 
 ( The outer name pretty fundamentally interacts with GREASE because the distribution of true SNIs is different from the distribution of cleartext ones , but the fact that IP addresses do n't get SNIs is an insignificant component of that , given how rare they are . Any reasonable model of GREASE distinguishability would need to be a bit more subtle . ) 
 If possible , I 'd like to see if we can drill down on where folks disagree . Fact 1 : The public name specifies the name that the client expects the client - facing server to verify in case of ECH rejection . Fact 2 : The outer SNI specifies the name the client expects the client - facing server to verify , regardless of whether ECH was offered . It seems like the point of disagreement is how these two extensions --- ECH and SNI --- are meant to be composed . It seems to me that believes that SNI takes precedence : if we allowed public name ! = outer  , then this would violate the rules of the SNI extension , It seems like believes that ECH can take precedence : allowing public name ! = outer  is OK because the client already knows what name the client - facing server will verify . Am I understanding this all correctly ? 
 I 'm very confused what facts 1 and 2 are trying to say . The servername extension , in any ClientHello , is the name of the server you 're trying to contact with that ClientHello . This figures into certificate selection , and you could even imagine a protocol which uses it in lieu of an in - band Host header for virtual hosting . ( Although HTTP does it in - band and does n't care much about the servername . ) In the ClientHelloInner , you are trying to contact the true name , so you put the true name in servername . In the ClientHelloOuter , you are trying to contact the public name , so you put the public name in servername . Independent of ECH , if you have external knowledge that such - and - such field will be interpreted in a different way and the server does n't need the server_name , then you can go against the spec . If that external knowledge applies to the ClientHelloOuter , then you can apply that to the ClientHelloOuter . But that 's not how the field is meant to work , so the spec should describe the intended semantics . 
 This seems to advocate that a SHOULD , rather than a MUST , is appropriate in choosing what name goes in ClientHelloOuter , right ? In particular , the spec does not accommodate external knowledge about what goes in the field . It requires it be set to ECHConfig.publicname . 
 I think a SHOULD is correct . Cheers ,     says that publicname is the name of the server when ECH is rejected ( i.e. , the client - facing server ) . Fact 2 says that servername is the name of the server . My point was merely that these facts appear to contradict one another if publicname ! = CHOuter.servername . Hence , we need to decide how to compose ECH with SNI in a way that resolves the contradiction . The answer might simply be that publicname MUST equal CHOuter.servername . Or , we might do say something else . 
 ( I do n't particular care about  vs. SHOULD . Whatever we say elsewhere for servername I guess . ) I 'm not following . I think talking about publicname ! = CHOuter.servername is getting causality the wrong way around . CHOuter is a construct we are inventing in ECH . That means we get to define the semantics . The semantics we 've defined are that CHOuter , along with the result of handshaking with CHOuter , is intended for the ECH rejection case . How does the client know how the ECH rejection case works ? Well , we also need to define that in ECH . Our definition is that you handshake against ECHConfig.publicname . Finally , servername is a construct that has already been defined . What goes in there ? RFC6066 and RFC8446 tell you . It 's the name of the server you are trying to contact . With all that , what do you put in CHOuter.servername ? Well , you put the rules together . It 's the name of the server you are trying to contact in the ECH rejection case , which is ECHConfig.public_name . 
 I do:- ) SHOULD seems correct to me . A MUST over - constrains generic libraries . I agree with the above but will quibble with some text below ... Not really - CHOuter has to be a " working " CH with semantics defined by 8446 , so we 're a lot more constrained in reality . Yep . That 's too absolute IMO . ECHConfig.publicname tells you a name that should work for the CHOuter fallback . There will be many situations where another name can work as well , though using ECHConfig.publicname is a fine default / SHOULD . Cheers ,   Oh sure . I was n't suggesting CHOuter and the resulting handshake get to ignore 8446 . But the parameters to that handshake are not set and that 's what ECH get to define . Hrm , in which link of the chain were you looking to add flexibility ? There 's : The implementation wants to set servername to some value other than the name they are contacting The implementation wants to set the name they are contacting to some value other than ECHConfig.publicname Weakening the first to SHOULD is perhaps plausible , especially if 6066 and 8446 already are less prescriptive . Weakening the second to SHOULD is much more dangerous because you lose the chain of authenticity up from the TLS handshake through X.509 to the name specified by the ECHConfig . 
 Let me try another way to justify a SHOULD . Consider SMTP / TLS . There can be 1 MX RR value for a domain . When forwarding a mail to it may ( or may not ) be that the correct way to handle ECH for SMTP / TLS is to look for an SVCB at or at one of the MX names that we find at It may ( or may not ) be the case that some or all of the server - side TLS endpoints for those MX names share the same ECHConfig private values at a given moment . It may ( or may not ) be the case that the DNS answers for  at all those MX names and are well managed and always in sync . It may ( and it will:- ) be the case that multiple MX name  RRs and multiple SVCB RR values including future new SVCB or ECHConfig extensions interact in ways the TLS WG ca n't now forsee . I think there could in future be a real use - case for ECH in SMTP / TLS , and that it 'd be wrong for the TLS WG to decide now with a MUST how ECHConfig.publicname ought be handled in all cases . I reckon many other protocols using TLS might also each have a pile of wrinkles we ca n't analyse . So I argue that at least generic libraries for TLS ought not be prohibited from having some kind of override that results in ! = ECHConfig.publicname . ( And for at least some generic libraries , contravening such a MUST would I think be a reason why upstream might reject an offered PR . ) All that said , using ECHConfig.public_name SHOULD work in almost all cases so is a good default and one to probably encourage . Hope that helps ,   : As an aside : some MX names expose what we 'd like to put in , whereas some will not , and a simple sub- string match wo n't always catch that . But that 's an issue for some mail folks to consider later , if it 's a real issue . ( It probably is n't for TLS , but maybe is for how MTAs might use multiple DoX queries . )
Paragraph (version A):
The non-empty name of the client-facing server, i.e., the entity
trusted to update the ECH configuration.  This is used to correct
misconfigured clients, as described in handle-server-response.
This value MUST NOT begin or end with an ASCII dot and MUST be
parsable as a dot-separated sequence of LDH labels, as defined in
RFC5890, Section 2.3.1.  Clients MUST ignore any "ECHConfig"
structure whose "public_name" does not meet these criteria.  Note
that these criteria are incomplete; they incidentally rule out
textual representations of IPv6 addresses (see RFC3986,
Section 3.2.2), but do not exclude IPv4 addresses in standard
dotted-decimal or other non-standard notations such as octal and
hexadecimal (see RFC3986, Section 7.4).  If "public_name" contains
a literal IPv4 or IPv6 address, the client SHOULD ignore the
"ECHConfig" to avoid sending a non-compliant "server_name"
extension on the ClientHelloOuter (see RFC6066, Section 3).
Paragraph (version B):
The DNS name of the client-facing server, i.e., the entity trusted
to update the ECH configuration.  This is used to correct
misconfigured clients, as described in handle-server-response.
Paragraph (version B):
Clients MUST ignore any "ECHConfig" structure whose public_name is
not parsable as a dot-separated sequence of LDH labels, as defined
in RFC5890, Section 2.3.1 or which begins or end with an ASCII
dot.
Paragraph (version B):
Clients SHOULD ignore the "ECHConfig" if it contains an encoded
IPv4 address.  To determine if a public_name value is an IPv4
address, clients can invoke the IPv4 parser algorithm in WHATWG-
IPV4.  It returns a value when the input is an IPv4 address.
Paragraph (version B):
See auth-public-name for how the client interprets and validates
the public_name.
Paragraph (version B):
Note that these rules may change in the presence of an application
profile specifying otherwise.
Paragraph (version B):
In verifying the client-facing server certificate, the client MUST
interpret the public name as a DNS-based reference identity.  Clients
that incorporate DNS names and IP addresses into the same syntax
(e.g.  RFC3986, Section 7.4 and WHATWG-IPV4) MUST reject names that
would be interpreted as IPv4 addresses.  Clients that enforce this by
checking and rejecting encoded IPv4 addresses in
ECHConfig.contents.public_name do not need to repeat the check at
this layer.