Subject: [TLS] Comment on draft-thomson-tls-sic-00

From: John Mattsson <[email-masked]>
Date: Fri, 29 Mar 2019 09:29:22 +0000

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

---

From: John Mattsson <[email-masked]>
Date: Fri, 29 Mar 2019 10:34:51 +0000

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 <[email-masked]>
Date: Friday, 29 March 2019 at 10:29
To: "[email-masked]" <[email-masked]>
Subject: Comment on draft-thomson-tls-sic-00

    Hi,

    

    Cheers,
    John

---

From: John Mattsson <[email-masked]>
Date: Fri, 29 Mar 2019 19:05:18 +0000

And one more....

"The 0xTBD flag can only be send in a ClientHello or CertificateRequest message.  Endpoints that receive a value of 1 in any other handshake message MUST generate a fatal illegal_parameter alert."

This goes against draft-nir-tls-tlsflags

"A server that supports this extension and also supports at least one of the flag-type features that use this extension and that were declared by the ClientHello extension SHALL send this extension with the intersection of the flags it supports with the flags declared by the client."

I assume the sic sic extension should be sent in EncryptedExtensions.

Cheers,
John

-----Original Message-----
From: John Mattsson <[email-masked]>
Date: Friday, 29 March 2019 at 11:34
To: "[email-masked]" <[email-masked]>
Subject: Re: Comment on draft-thomson-tls-sic-00

    

    
    Cheers,
    John
    
    -----Original Message-----
    From: John Mattsson <[email-masked]>
    Date: Friday, 29 March 2019 at 10:29
    To: "[email-masked]" <[email-masked]>
    Subject: Comment on draft-thomson-tls-sic-00
    
        Hi,

        

        Cheers,
        John