Hi,
> RFC6347, 4.1.2.7. Handling Invalid Records
> …
> In general, invalid records SHOULD be silently discarded, thus preserving the
> association;
During a handshake only the new association will be affected and therefore no
(current) association could be preserved with silently discarding rec
I don't think it's necessary going to that degree of detail. For your specific
first example, alert the alert "bad_certificate" is enough, or at the most a
"certificate_chain_length_error". Your second example is, for me, more real,
because it can be an extended error for a "decode_error" alert.
Ion Larranaga Azcue writes:
>I don't think it's necessary going to that degree of detail. For your
>specific first example, alert the alert "bad_certificate" is enough
We already have error codes at about that level. They're not enough to debug
any problems (I mean, "bad certificate" is only ma
I think you don't really get my position in this issue... No, I'm not going to
start a list of numeric codes because I don't believe in this functionality.
Not even numeric extended alert codes have any appeal to me, it's just the
least offending idea.
In my opinion, someone wants this function
> The webpki is changing dramatically. The amount of CAB/forum violations
> seems to be increasing, partially as a result of these violations getting
> exposed
> by certificate transparancy and perhaps partially because of the financial
> strain
> caused by the free LetsEncrypt.
Uniformed specul
Hello,
PR#1163 in draft-26 seems to have broken interop with previous drafts
with a variety of deployed implementations. draft-26 and later clients
fail with a protocol_version alert.
Affected Internet servers include:
cloudflare.com: offers draft-23, intolerant to draft-26
www.apple.com: seemin
On Mon, Apr 09, 2018 at 10:16:06PM +0100, Joseph Birr-Pixton wrote:
> Hello,
>
> PR#1163 in draft-26 seems to have broken interop with previous drafts
> with a variety of deployed implementations. draft-26 and later clients
> fail with a protocol_version alert.
>
> Affected Internet servers inclu
Your results are not really very surprising.
Different folks are at different drafts, and "everyone" is waiting for the
final RFC to be published and upgrade then.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Mon, Apr 9, 2018 at 2:16 PM, Joseph Birr-Pixton
wrote:
> Hello,
>
> PR#1163 in draft-26 seems to have broken interop with previous drafts
> with a variety of deployed implementations. draft-26 and later clients
> fail with a protocol_version alert.
>
> Affected Internet servers include:
>
> cl
On 9 April 2018 at 22:29, Eric Rescorla wrote:
> PR#1163 was just about what the server sends.
Aha. This is the bit I missed. I had interpreted "you can't negotiate
pre-TLS 1.3 with supported_versions" applied to both ends.
Thanks!
Joe
___
TLS mailing
> On Apr 7, 2018, at 8:37 PM, Peter Gutmann wrote:
>
> I can't believe the amount of pointless bikeshedding that's already been done
> over something that's going to be a rarely-if-ever used mechanism for one set
> of hardcore technical developers to communicate to another set of hardcore
> tec
11 matches
Mail list logo