<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Mon, Jan 21, 2019, 9:20 AM Achim Gratz via devel <<a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hal Murray via devel writes:<br>
>> My thought about how to enable NTS for the pool would involve requiring a SRV<br>
>> record lookup for NTS-KE<br>
><br>
> That SRV lookup could return multiple names.  Each would point to a separate <br>
> NTS-KE server.<br>
><br>
> An alternative approach would be to extend the NTS-KE protocol to support <br>
> multiple answers.<br>
<br>
No, the client needs to ask multiple times.  Otherwise each association<br>
for that TLS session would get the same S2C and C2S keys and that's a<br>
no-no.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Not seeing a viable exploit ATM. One would need to get a server in the pool, a ridiculous amount of computer power and/or an exploit against AES and/or ChaCha as well as acesss to the packet stream of a given host which puts it out of the range of almost anyone except *no such agency*.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>