Alan DeKok wrote:
>> I personally fine with writing MUST send an Error alert if the WG wants
>> that.
>
> This is what all implementations have done for ~15 years. The TLS Alert
> satisfies the "altReject"
> requirements of RFC 4137. Which means it's a very good iea.
Jorge said offline th
On Feb 6, 2021, at 1:01 AM, John Mattsson
wrote:
>
> I personally fine with writing MUST send an Error alert if the WG wants that.
This is what all implementations have done for ~15 years. The TLS Alert
satisfies the "altReject" requirements of RFC 4137. Which means it's a very
good iea.
Hi,
I personally fine with writing MUST send an Error alert if the WG wants that.
This would maybe help with using close_notify as an alternate success
indication.
The most pressing question regarding alerts is if EAP-TLS can force the TLS
implementation to not use close_notify in any situatio
On Feb 5, 2021, at 2:53 PM, Alan DeKok wrote:
> The TLS layer generally *will* produce TLS alerts. The application has the
> choice whether or not to send them. i.e. it should just discard the TLS
> alerts, and instead send EAP-Failure.
Typo, sorry. It "could" discard the TLS alert and se
On Feb 5, 2021, at 2:46 PM, John Mattsson
wrote:
>
> I see now that the two paragraphs you send seems to be contradicting each
> other
>
> https://tools.ietf.org/html/rfc8446#section-2
>
> A failure of the handshake or other protocol error triggers the
> termination of the connection, opt
Hi,
I see now that the two paragraphs you send seems to be contradicting each other
https://tools.ietf.org/html/rfc8446#section-2
A failure of the handshake or other protocol error triggers the
termination of the connection, optionally preceded by an alert
message (Section 6).
https://
