Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

> 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

[TLS] New version intolerance caused by draft-26 supported_versions change?

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:

Re: [TLS] New version intolerance caused by draft-26 supported_versions change?

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

Re: [TLS] New version intolerance caused by draft-26 supported_versions change?

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

Re: [TLS] New version intolerance caused by draft-26 supported_versions change?

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

Re: [TLS] New version intolerance caused by draft-26 supported_versions change?

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

> 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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

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

Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ?

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

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