Re: [TLS] Ticket request PR#20
On Sun, Apr 19, 2020 at 03:41:49PM -0700, Eric Rescorla wrote:
> I don't think we should make this change. In the context of this draft, if
> the client wants that behavior, it should send {1, 1}.
That precludes clients from soliciting 0 *only* from servers that
support some future specification, and otherwise getting 1 from
servers that support only the current specification.
Such clients are not looking for a static server behaviour, but
rather need only certain servers to return 0, and the rest
to return 1.
In any case, if sending 1 or more unconditionally was fine for RFC8446
(e.g. per the text in C.4) it is hard to imagine why it is suddenly so
important to insist that the server be able to send 0 when receiving
{1, 0} or {0, 1}.
Servers that don't support this new extension at all will send 1 (or
more). So it is clearly not a big deal also for servers that do
support it to do likewise.
Since there is no specific *use-case* for {1, 0} to mean 0 at present,
that couldn't also be handled by sending {0, 0}, there is no reason
to stand in the way of defining {1, 0} to be a solicitation for at
least 1 ticket regardless of the handshake type.
The only objection that makes sense is a blocking tactic to preclude
potential future refinement of this draft to support reuse, but surely
blocking that evolution can be deferred to the discussion of the
(misguided?) I-D that proposes it.
--
Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ticket request PR#20
I don't think we should make this change. In the context of this draft, if
the client wants that behavior, it should send {1, 1}.
-Ekr
On Sun, Apr 19, 2020 at 3:23 PM Viktor Dukhovni
wrote:
> I uploaded a small pull request for the ticket request draft:
>
> https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/20
>
> it stipulates that servers SHOULD send at least one ticket unless *both*
> counters are zero. A client willing to accept tickets for either of the
> two handshake types is capable of accepting a ticket for the other.
>
> Yes, this leaves the door open to later define (or not) special
> semantics for the zero value to be used between mutually consenting
> clients and servers.
>
> --
> Viktor.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Ticket request PR#20
I uploaded a small pull request for the ticket request draft: https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/20 it stipulates that servers SHOULD send at least one ticket unless *both* counters are zero. A client willing to accept tickets for either of the two handshake types is capable of accepting a ticket for the other. Yes, this leaves the door open to later define (or not) special semantics for the zero value to be used between mutually consenting clients and servers. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Epochs for ACKs
I have posted a PR to clarify this: https://github.com/tlswg/dtls13-spec/pull/142 On Tue, Apr 14, 2020 at 1:13 AM Hanno Becker wrote: > Hi all, > > On ACK protection, DTLS 1.3 Draft 37 says in Section 7: > >ACK records MUST be sent with an epoch that is equal to or higher >than the record which is being acknowledged. Implementations SHOULD >simply use the current key. > > Since the update of incoming and outgoing keying material is > independent, I don't know how this can be enforced: After a > sequence of key updates, the incoming epoch might be 42 while > the outgoing epoch is 17. > > What problems arise if one replaces the paragraph by the following: > >ACK records MUST be sent with the current key, irrespective >of the epoch that is used to protect the record that is >being acknowledged. > > It appears that the paragraph is particularly relevant for the case > of ACKing a ServerHello, which as far as I understand shall happen > with epoch 1. Since 'current key' doesn't appear unambiguously > defined at the point of the client processing the ServerHello, it > might be worth spelling out this case explicitly. > > Best, > Hanno > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Weekly github digest (TLS Working Group Drafts)
Issues -- * tlswg/draft-ietf-tls-esni (+5/-0/💬11) 5 issues created: - two type codes needed for interop (by sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/220 - cardinality of ECHOConfig vs. HTTPSSVC (by sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/219 - HPKE code points vs. TLS ciphersuites (by sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/218 - ECHOConfigContents.extensions is not needed (by sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/217 - where servers put CH details/hints: ECHOConfig or HTTPSSVC? (by sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/216 3 issues received 11 new comments: - #219 cardinality of ECHOConfig vs. HTTPSSVC (2 by davidben, sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/219 - #216 where servers put CH details/hints: ECHOConfig or HTTPSSVC? (5 by bemasc, davidben, sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/216 - #214 Clarify whether ClientHelloInner can support TLS 1.2. (4 by chris-wood, sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/214 Pull requests - * tlswg/draft-ietf-tls-esni (+0/-1/💬0) 1 pull requests merged: - README: fix links to WG docs https://github.com/tlswg/draft-ietf-tls-esni/pull/213 * tlswg/draft-ietf-tls-ticketrequest (+0/-2/💬0) 2 pull requests merged: - Ticket request with separate resumption and new_session counts. https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18 - Use two counters for fresh and resumed connections https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/19 Repositories tracked by this digest: --- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
