I think, like the tracking issue, it should go in both. (I wrote https://github.com/tlswg/tls13-spec/pull/1205 to try to capture the tracking case.) This draft should definitely (re)-state it because TLS preferences are most common keyed by domain name. So even if it's in TLS itself, it's worth emphasizing it.
At the same time, I think it is a general property of resumption. An application may have different TLS preferences even for a single domain. (E.g. web browsers make both credentialed and uncredentialed requests, which are supposed to imply different client certificate preferences.) Or maybe you have some contexts with different server authentication preferences than other contexts. Such an application would need to adjust its resumption behavior accordingly. To me, the ideal state would be that TLS contains the long-form general guidance and then this draft cites TLS as a reminder, because keying preferences by domain is so common. But since the order between rfc8446bis and this draft isn't yet clear, probably we restate the rules in full in both and, after rfc8446bis is done, documents can be more concise. On Thu, Dec 3, 2020 at 4:00 PM Eric Rescorla <e...@rtfm.com> wrote: > Hmmm... I think it probably goes in this draft, but I'm open to being > wrong. > > On Thu, Dec 3, 2020 at 12:46 PM Salz, Rich <rs...@akamai.com> wrote: > >> >> - I'm not sure if it's ever been written down anywhere (probably >> should be...), but I think resumption is pretty much universally >> interpreted as authenticating as the identities presented over the >> original >> connection, client and server. That means that, independent of this draft, >> the client should only offer a session if it is okay with both accepting >> the original server identity, and presenting the original client identity. >> (Analogously, HTTP connection reuse reuses TLS handshake-level decisions, >> so you have to be okay with that decision to reuse the connection.) >> >> >> >> Totally agree. @ekr, you want to make this change in your BIS draft? >> >> >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
