Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

Hi Tom, > I think that I cannot make sense of that 'alternately'. The subsequent > paragraphs seem to rule it out as an option. On a first read I thought > that a zero length CID was a valid option for Application Data and > wanted to know which form of header and MAC was appropriate but my > u

Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

Hi Tom, all, On 12/03/2021, 17:29, "tom petch" wrote: > On 12/03/2021 16:18, Achim Kraus wrote: > > Hi Tom, Hannes, Thomas, > > > > "A zero-length value indicates that the server will send with the > > client's CID but does not wish the client to include a CID (or > > again, alternately, to use a

Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

On 12/03/2021 16:18, Achim Kraus wrote: Hi Tom, Hannes, Thomas, "A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID (or again, alternately, to use a zero-length CID)." My feeling is, the text in the paragraphs following

Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

Hi Tom, Hannes, Thomas, "A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID (or again, alternately, to use a zero-length CID)." My feeling is, the text in the paragraphs following that seems to introduce first the idea of a

Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

Hi Tom, I added a few PRs to address your review (see https://github.com/tlswg/dtls-conn-id/pulls). Regarding the zero-length CID I believe the current version in the repo at https://github.com/tlswg/dtls-conn-id might have already address your remark. In general, the zero-length CID in the Cl

Re: [TLS] last call: draft-ietf-kitten-tls-channel-bindings-for-tls13-02

Hi Watson, Exporters are a form of channel binding (in the protocol theory sense, not in the RFC 5056 sense). Two protocols that use the defined binding on a single TLS connection will derive the same Exporter. This is clearly intended to be generic, the input string is "EXPORTER-Channel-Binding"

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

I don't believe so, but that would seem like a configuration issue. I guess if you really wanted you could define an extension that goes in the Certificate Request message (which the AR is based on), assuming there isn't one already, that requests a specific serial number. Although that of course

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

Hi Jonathan, Maybe a further question to the draft you referenced (exported authenticators). Is there a way to request a distinct certificate in the AuthenticatorRequest? Can I ask for the certificates used in the initial handshake from both sides? I saw in the extension that in the ClientCerti

Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

Hi Tom, Thanks very much! Your review is tracked in the issues below. On 12/03/2021, 10:39, "tom petch" wrote: > > Some editorial quirks > > s.2 > lacks the boiler plate of RFC8174 https://github.com/tlswg/dtls-conn-id/issues/88 > s.3 > I found this unclear until I had understood it all (or p

Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

Some editorial quirks s.2 lacks the boiler plate of RFC8174 s.3 I found this unclear until I had understood it all (or perhaps I do not understand it) "...or again, alternately, to use a zero-length CID)." This suggests that a zero length CID is valid in Application Data which later text see