On Thu, May 10, 2018 at 1:48 PM Viktor Dukhovni
wrote:
> I may be misreading the code, but it sure looks like the alert is only
> sent if the application callback for the server name extension asks
> OpenSSL to do that. The application can just decline the extension
> and let the handshake conti
TLS 1.3 allows clients to send multiple PSK identities, with the server
choosing one. When, if every, might it make sense for the client to
send multiple session tickets to the server? If this is not expected,
is it sufficiently odd for a server to ignore any tickets after the
first (if that one
On Wed, May 9, 2018 at 7:15 PM, Martin Thomson
wrote:
> I'm not that concerned about this, though I will concede that it's worth
> pointing out.
>
> Failing to validate a secondary certificate for a server shouldn't be cause
> for terminating an otherwise usable connection.
To be clear: it's no
> On May 9, 2018, at 10:07 PM, Martin Thomson wrote:
>
> This alert is actually fairly common (though I'm surprised to see OpenSSL
> still doing it) and clients need to handle it, unfortunately.
I may be misreading the code, but it sure looks like the alert is only
sent if the application cal
Reject. The text refers to the output of the AEAD. The contents of the
"aead-cipher struct" are the inputs.
On Thu, May 10, 2018 at 2:17 AM RFC Errata System
wrote:
> The following errata report has been submitted for RFC5246,
> "The Transport Layer Security (TLS) Protocol Version 1.2".
>
I'm not that concerned about this, though I will concede that it's worth
pointing out.
Failing to validate a secondary certificate for a server shouldn't be cause
for terminating an otherwise usable connection. The same goes for clients
that authenticate using this. As long as users of exported
This alert is actually fairly common (though I'm surprised to see OpenSSL
still doing it) and clients need to handle it, unfortunately. Before the
client has any confirmation that it is doing TLS 1.3, it has to assume that
the server is any TLS version.
Of course, if the client isn't prepared to
But it actually sends an SH? That seems odd and kind of an ambiguous point
in the spec.
-Ekr
On Wed, May 9, 2018 at 10:14 AM, Roelof duToit wrote:
> In one of our tests OpenSSL 1.1.1-dev sends an unrecognized_name warning
> alert before a TLS 1.3 (draft 26) ServerHello. Alert level is suppose
In one of our tests OpenSSL 1.1.1-dev sends an unrecognized_name warning alert
before a TLS 1.3 (draft 26) ServerHello. Alert level is supposed to be
implicit in TLS 1.3, but in this case it is ambiguous. Should it even be
considered a “TLS 1.3 alert” given that it arrives before the protocol
The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".
--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5352
--
Type: Technical
Rep
Regardless of where it goes in the document, I think there's a real
deployment
consideration here: if you run this mechanism through a conventional MITM
proxy, what will happen will be that the secondary cert auth will appear to
just
fail with a bogus signature. If clients respond to that by termin
>Perhaps, but it still behooves us to warn implementors that a significant
> percentage of enterprise traffic will break with this mechanism.
Why do you think a significant percentage will break?
___
TLS mailing list
TLS@ietf.org
https://www.iet
Perhaps, but it still behooves us to warn implementors that a significant
percentage of enterprise traffic will break with this mechanism.
> On May 9, 2018, at 3:39 AM, Martin Thomson wrote:
>
> This isn't really a security consideration though, it's a truism. A MitM
> can break things that de
This isn't really a security consideration though, it's a truism. A MitM
can break things that depend on end-to-end integrity of the connection.
On Wed, May 9, 2018 at 11:25 AM Roelof duToit wrote:
> If the use of the mechanism is not negotiated on the TLS level then I
would appreciate it if the
14 matches
Mail list logo
