It seemed worth copying this to the WG list; sorry for those getting an extra copy.
-Ben On Sun, Jul 21, 2019 at 10:26:56AM -0400, Martin Thomson wrote: > On Sat, Jul 20, 2019, at 21:57, Benjamin Kaduk wrote: > > > already supported by TLS libraries? Also, are we in effect deprecating > > > this TLS > > > 1.3 feature because of the security issue of the mismatched record > > > boundaries? > > > > I think in some peoples' minds that would be a good thing, though it's not > > entirely clear that we are actually doing so. > > This wouldn't deprecate post-HS auth. It is intended to cover the cases > where post-HS auth does not work. See > draft-ietf-httpbis-http2-secondary-certs. > > > > "SHOULD use TLS", change to MUST. There's no way it can work otherwise > > > anyway. > > > > What about QUIC? > > I think that we can safely regard QUIC (at least those versions that use TLS) > as TLS. An informative mention might help avoid any confusion regarding this > point. We might also regard DTLS-SRTP as one such protocol. > > > > * Is > > > there a requirement for all protocol messages to be sent over a single TLS > > > connection? If so, please mention it. Certainly this is true for the > > > Authenticator message that must be sent over a single connection and > > > cannot be > > > multiplexed by the high-level protocol. I think this protocol actually > > > assumes > > > "nice" transport properties (no message reorder, reliability) that also > > > require > > > a single, clean TLS connection. > > > > It seems like we should be more clear about what we do (and do not) > > require. Though IIRC we can do separate authenticators in parallel and not > > require them to be ordered with respect to each other. > > See above regarding DTLS-SRTP. Being too crisp might constrain usage > inappropriately. > > > > * Why no authenticator request for servers? > > > Don't we care about replay? OTOH if the client wants to detect replays, it > > > would need to keep state on received authenticators, which would be very > > > messy. > > > > IIUC the thinking is that there's no way to revoke an authenticator for a > > connection, so replay (if not detected by another layer anyway) would not > > cause the authentication state to change. > > Ben is correct. > > > > * 7.1: this is > > > changing TLS 1.3 by allowing this extension in Cert Request! I think it's > > > a > > > really bad idea. Better to hack special support to existing libraries, > > > allowing > > > this specific extension for this special case, than to change the base > > > protocol. Otherwise, this document should UPDATE 8446. > > > > Or, since extension codepoints are cheap, just use a newcodepoint. > > We might want to discuss this one this week if we can. > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
