Hi Nick,
Thanks for reviewing the doc, please see further responses/comments below:
On 8/17/20, 8:40 AM, "TLS on behalf of Nick Lamb" <tls-boun...@ietf.org on
behalf of n...@tlrmx.org> wrote:
I am not very familiar with IETF working group practices, however it
strikes me as surely unusual to have a document enter Last Call
(supposedly believed by its owners to be ready for publication) and yet
immediately then be revised showing it was in fact not ready at all.
[NCW] It was an unfortunate oversight on my part as I somehow did not catch
Tom's feedback when I updated the draft until he pointed it out and I had to
go to the opsec mailarchive to retrieve his initial comments.
I don't believe, we the authors made any notion that we were ready for
publication;
I believe the last call process is to ensure there is more review before
publication.
However this seems to be what happened to draft-ietf-opsec-ns-impact.
The below comments concern draft-ietf-opsec-ns-impact-02, the newer
document.
Section 4.1 Perfect Forward Secrecy ends:
> TLS session data.ss
I think this is a typographical error and the trailing "ss" should be
removed from the document. If not it should be explained.
[NCW] Thanks for catching it, a formatting remnant which will be removed.
Section 4.2 Encrypted Server Certificate describes a practice which is
inherently unsound. Passive inspection of the Certificate message from
TLS 1.2 or earlier isn't a reliable source of information because a
passive eavesdropper isn't able to discern whether the X.509 document
presented corresponds to this server or not. The Client can confirm
this using the TLS protocol but an eavesdropper can't. So the change in
TLS 1.3 does not impact the practical security policy available, only an
appearance is altered.
[NCW] The document describes what is in practice today with TLS 1.2 and 1.1
whether we believe it is unsound or otherwise, it is what is done today.
Passive systems described throughout Section 5.1 fall to this same
error, using the phrase "reduced effectiveness" which the document
defines as not being "as effective on TLS 1.3 traffic" but in fact
since this practice didn't work, it will remain exactly as effective
(not at all) as before.
[NCW] Again, the document is describing what is in practice today.
A related consequence passes into Section 5.2. Since the Certificate
message is only reliable for a Client, it has in fact always been
necessary to fully proxy the TLS session in order to rely on this data,
so this is not in fact an impact from TLS 1.3 but (if it wasn't done
previously for all versions) a vulnerability in such products.
[NCW] With TLS 1.2 the observer can see the handshake thru completion
with the Finished message before affecting a policy decision.
As it stands then, this document is misleading.
Nick.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
