Hiya, (Non-stylishly responding to myself, but sometimes you gotta...:-)
I think I understand this better now and while I still
figure a change is needed I'm not 100% sure exactly what'd
be right.
The issue I think is that draft-04 doesn't cover the case
of a server that implements ESNI but has no ESNIKeys setup,
In that case I think the right option in response to GREASE
(or what may be a real but misguided attempt at ESNI) is to
randomly return either a 16 octet value or a value that is
sized to be like a fake ESNIKeys, with e.g. 70-100 octets or
so. (That could be encoded into TLS presentation syntax in
various ways so I'll not suggest one exact way for now.)
(Before I waste time coding that up:-) Do we think the
above is correct?
Thanks,
S.
On 26/07/2019 18:31, Stephen Farrell wrote:
>
> Hiya,
>
> I've started coding up the GREASE stuff from draft -04.
>
> Aren't we missing some answering octets in EncryptedExtensions
> to make it harder to tell if the CH had a real or GREASEd ESNI?
>
> Maybe something like:
>
> enum {
> esni_accept(0),
> esni_retry_request(1),
> esni_grease(2),
> } ServerESNIResponseType;
>
> struct {
> ServerESNIResponseType response_type;
> select (response_type) {
> case esni_accept: uint8 nonce[16];
> case esni_retry_request: ESNIKeys retry_keys<1..2^16-1>;
> case esni_grease: uint8 grease[16];
> }
> } ServerEncryptedSNI;
>
> Cheers,
> S.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
