Some more comments after reading the draft in detail.
- The abstract and introduction only talks about the ClientHello use case.
Should shortly mention the CertificateRequest use case as well.
- I notice that the draft does not have any requirement on how the client gets
access to the intermediary certificates. I think this is the right approach.
The problem discussed in EMU is that that many access points drops EAP
connections after 40 - 50 packets and that EAP-TLS connections with large
certificate chains may therefore be unable to complete.
One approach discussed in EMU is that the client could take intermediate
certificates from an earlier EAP-TLS connection that was dropped by the access
point. This drafts currently allows that. I think that is correct. I cannot see
that the distribution of intermediary certificates need any security
requirements as the client can verify them with the help of one of its trust
anchors.
Cheers,
John
-----Original Message-----
From: John Mattsson <john.matts...@ericsson.com>
Date: Friday, 29 March 2019 at 10:29
To: "TLS@ietf.org" <TLS@ietf.org>
Subject: Comment on draft-thomson-tls-sic-00
Hi,
I am strongly supporting of solving the problem this draft is trying to
solve. This is a problem that the EMU WG has identified and discussed in the
past.
https://tools.ietf.org/html/draft-ms-emu-eaptlscert-02
I will add text discussing draft-thomson-tls-sic-00 to
draft-ms-emu-eaptlscert-03 and ask for agenda time in EMU at IETF 105 to
discuss if draft-thomson-tls-sic-00 solves the problems of the EMU WG.
The EMU WG actually shortly discussed this Monday if the WG thought there
was any updates to TLS that needed to be driven in the TLS WG.
Cheers,
John
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
