On Mon, Jul 11, 2022 at 05:03:03PM -0400, Ben Schwartz wrote: > Thanks for the detailed review! I've proposed some changes to address most > of your comments (https://github.com/tlswg/draft-ietf-tls-ctls/pull/70). > Some additional questions below. > > On Sun, Jul 10, 2022 at 11:54 AM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > On Sat, Jul 09, 2022 at 02:32:07PM -0700, internet-dra...@ietf.org wrote: > > > ... > > > Reviewing this (again after version update): > > > > > > 1) Section 1. Introduction: > > > > > More compact encodings, for example point compression. > > > > I think it would be better to define compact versions of NIST curves > > (and maybe Brainpool curves too) and register those into supported > > groups registry (where those could also be used in (D)TLS). > > > > Would this actually help in ordinary (D)TLS, or would the extra bytes > needed to advertise the additional supported algorithms in the ClientHello > outweigh the savings from a compact representation?
Not quite sure if I understand right, but adding 3 compact NIST curves and replacing P-256 -> P-256-compact for share would be net 27 octets saved (33 for smaller share, minus 6 bytes for extra groups). > ... > > > 3) Section 2.1.1. Initial template elements > > > > I think the following should be added: > > > > - More efficient ECDSA signature encoding. Right now, ECDSA signatures > > use ASN.1 encoding, which is very inefficient in communication- > > constrained environments. Using simple concatenate-raw-r-and-s > > encoding would be more efficient. > > > > Would you do this by registering new SignatureSchemes, similar to your idea > of defining new NamedGroups above? I had an idea for compression knob to do this, but I suppose SignatureScheme could be used too. > > > - Option to force extension blocks on any chain certificates to be > > empty. Those are very rarely used for anything. > > > > Could you clarify what you mean by "chain certificates"? Are you including > leaf certificates in that definition? Oh, sorry. All except the leaf. > I have the impression that Signed Certificate Timestamps and OCSP Stapling > both use CertificateEntry.extensions, and are widely used, including on > intermediate certificates. Yes, both SCTs and OCSP use ce-extensions. I do not think I have ever seen those used on intermediates. WebPKI rules make intermediate OCSP stapling useless (there are more serious PKIs where using intermediate OCSP would be useful tho). Intermediate stapling of SCTs would be useful for some usecases, but what servers support that? The TLS implementation I have written does support OCSP and SCT stapling on leaf certificate (both sending and receiving), but the intermediate extensions is hardcoded to be empty when sending, and those extensions are mostly ignored (parsed, but not anything else). > ... > > > 9) Section 2.2. Record Layer > > > > The E bits should presumably be hardwired to zero on reliable/ordered > > transports. As reliable/ordered corresponds to TLS 1.3, and TLS 1.3 > > has no equivalent of E bits (as it never needs to handle out-of-order > > key update). > > > This is an interesting question. I would expect that the E bits are set by > the sender as they would be for DTLS, and perhaps are ignored by the > receiver. However, I suppose this might reveal the use of KeyUpdates that > would otherwise be undetectable... Another way to look at it: TLS has no epoch (searching RFC 8446 for "epoch" gives nothing), epoch is DTLS-specific concept. Another thing: ScTLS can not migrate (TLS requires reliablity, but DTLS/QUIC-style migration requires unreliability) and inherently requires channeling from underlying transport, so I do not think connection ID makes any sense in ScTLS. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
