I think this is more-or-less ready and I support
publication. My comments below, none of which are
show-stoppers but they might be worth a look.
Cheers,
S.
Shouldn't there be some mention of CT here somewhere?
Say if we have a good solution, but the hidden service's
cert is in CT logs, then an adversary can find those, and
see what it gets from DNS for those names (from different
vantage points) and how that correlates with addresses.
And if the certs for hidden services are special in any
way, that gets worse. (Implying that we don't want the
certs for the hidden services to be special in any way I
guess?)
HTTP fronting - I guess the situation has changed a bit
with respect to this over the time that the draft has been
evolving. Do we want to note that?
As a process-issue, I'm not sure if it'd be better or
worse to send this for publication now or wait until the
esni work has progressed some more. I don't mind either
way myself, but I guess the question'll be asked if we do
shoot it forward now, (given that some people apparently
dislike this kind of RFC;-). It'd be no harm to have the
answer on the list if that's the plan - so why publish
now, given that esni is under development?
nits:
abstract: might be worth saying that we don't expect
solutions to necessarily meet all requirements here.
(That's stated in the security considerations, but could
be worth adding here.)
2.1: is it worth noting debugging tools like wireshark
here?
2.2: Are all of the things mentioned in 2.1 "abuses"?
I'm not sure everyone would agree. It might be worth doing
s/abuses/uses and abuses/ here to avoid a fuss at IETF LC
time.
2.2: "make it much harder" is maybe overstated?
3.4: There's the inevitable issue with not sticking out.
That being that it tends to increase the centralisation of
the Internet, in this case reducing the number of entities
to which pressure needs to be applied by the adversary.
Worth a mention here?
Hiya,
I think this is more-or-less ready and I support publication. My comments below, none of which are show-stoppers but they might be worth a look.
Cheers, S.
Shouldn't there be some mention of CT here somewhere? Say if we have a good solution, but the hidden service's cert is in CT logs, then an adversary can find those, and see what it gets from DNS for those names (from different vantage points) and how that correlates with addresses. And if the certs for hidden services are special in any way, that gets worse. (Implying that we don't want the certs for the hidden services to be special in any way I guess?)
HTTP fronting - I guess the situation has changed a bit with respect to this over the time that the draft has been evolving. Do we want to note that?
As a process-issue, I'm not sure if it'd be better or worse to send this for publication now or wait until the esni work has progressed some more. I don't mind either way myself, but I guess the question'll be asked if we do shoot it forward now, (given that some people apparently dislike this kind of RFC;-). It'd be no harm to have the answer on the list if that's the plan - so why publish now, given that esni is under development?
nits:
abstract: might be worth saying that we don't expect solutions to necessarily meet all requirements here. (That's stated in the security considerations, but could be worth adding here.)
2.1: is it worth noting debugging tools like wireshark here?
2.2: Are all of the things mentioned in 2.1 "abuses"? I'm not sure everyone would agree. It might be worth doing s/abuses/uses and abuses/ here to avoid a fuss at IETF LC time.
2.2: "make it much harder" is maybe overstated?
3.4: There's the inevitable issue with not sticking out. That being that it tends to increase the centralisation of the Internet, in this case reducing the number of entities to which pressure needs to be applied by the adversary. Worth a mention here?