Hi,
Note that close_notify (no more data) is not an exact replacement for the
Commitment Message (no more handshake data). A change from 0x00 to close_notify
invalidates Figure 6: EAP-TLS unsuccessful client authentication in the
document.
EAP Peer
Hi,
Reading up on the mail discussion more (I have been on parental leave), I don't
see any real motivation for this late technical change suggestion...
Hannes wrote that the draft-ietf-emu-eap-tls13 does not work with Mbed because
it introduces a new message and requires unencrypted data. One
On Sep 1, 2020, at 8:24 AM, John Mattsson wrote:
> Reading up on the mail discussion more (I have been on parental leave), I
> don't see any real motivation for this late technical change suggestion...
My $0.02 is that it's philosophical. EAP-TLS does authentication using TLS.
Adding an ext
Hi,
If the ability to send a descriptive TLS Fatal Alert back to the peer is a
requirement, changing to close_notify seems like a bad idea. My understanding
is that is would add an extra roundtrip without any clear benefits compared to
sending an encrypted 0x00 application data.
EAP Peer
Hi,
I have reviewed draft-ietf-emu-tls-eap-types-01. Looks good. Two crypto related
comments below:
- "MAC is the MAC function negotiated in TLS 1.3."
There is no MAC function negotiated in TLS 1.3. Also, a modern TLS
implementation would not negotiate any MAC funtion in TLS 1.2 as they would
On Sep 1, 2020, at 12:05 PM, John Mattsson
wrote:
>
> I have reviewed draft-ietf-emu-tls-eap-types-01. Looks good. Two crypto
> related comments below:
>
> - "MAC is the MAC function negotiated in TLS 1.3."
>
> There is no MAC function negotiated in TLS 1.3. Also, a modern TLS
> implementati
>> This raises the question what TEAP TLS 1.2 implementations do today? Are
>> they only using outdated and non-secure cipher suites or are they doing
>> something unspecified to derive Compound-MAC with an AEAD cipher suite?
> It's not clear. I'd have to double-check hostap, which is the only
