Draft: draft-ietf-tls-tls13

Commentary: There is no reason from cryptographical point of view to not resume across multiple domains . The primary concern comes from interoperability concerns and potential waste of tickets , hence the default should be to not resume . 
 This looks plausible . Can you please email the list ? 
 It 's perhaps more text than is needed to convey the point , but I do not object to the change itself . It may be worth explicitly calling out the divergence from RFC 6066 , though . ( Also , I note that we require external PSKs to be provisioned with SNI for use with 0 - RTT , though there does not seem to be a corresponding change needed to that text . ) 
 I 'm fine with this as long as it does not create new security problems . My sense is that this is no worse than the current situation , because the client only will do this if the server has shared certs , which is one of the cases where caution is already required based on http://antoine.delignat- could you weigh in ? 
 Enabling cross - domain resumption unconditionally is still a dodgy idea for the same reasons that it was back in 2015 . The main issue is that it introduces a discrepancy between the application - level security policy ( which is still mostly origin based for HTTP ) and the transport - level guarantees when applied to the full certificate rather than only the SNI of the connection . To summarize the WWW'15 paper , the key observation is that it is actually very common in practice for origins with different application - level security policies to appear in the same certificate . The top 2 reasons why this happens is 1 . wildcard / SAN certificates 2 . CDN and other name - based cloud hosting . The later is particularly bad , because it means an attacker may be able to get his website to appear in the same certificate as an honest website it tries to attack - such an attacker becomes incredibly powerful in particular if a multi - stream application protocol such as HTTP/2 , or QUIC is used for stream multiplexing above encryption ( I do n't believe any of the published theorems on TLS or QUIC security provide any security against this attacker ) - for instance , CRIME - like attacks may become possible again . The main way to exploit such discrepancies that I know of relies on the fact that most HTTP requests fallback to the default virtual host if the " Host " header of the request does not match any configured VH . Since it is commonly the case that separate servers / virtual machines are used for the different names in a certificate ( or subdomains with wildcard ) , redirecting requests from one server to another causes pages to be loaded under the wrong origin . This lets you " port " web vulnerabilities ( or lack of strong security , e.g. CSP / HSTS ) from one domain to the other . I have tried to convince webserver developers such as apache and nginx that this behavior is too dangerous but since then given up on trying to remove this fallback - to - default mechanism ( it simply breaks too much of the Web ) . I do n't know whether current implementations of HTTP/2 still have this behavior - if they do , I think it is too much of a risk to allow cross - domain resumption unless it is explicitly enabled . If they do n't , I suggest that this feature is only made available if the negotiated ALPN is NOT http/1.1 or older . In addition , it is worth noting that cross - domain , same - certificate sharing breaks many proposed or deployed transport - level security mechanisms , including HSTS ( see the paper for attack example ) , but also Token Binding / Channel ID ( for instance , this may allow a network+web attacker to force Token - bound cookies on a website for which it shares a certificate ) . 
 Do n't most of the arguments against cross - domain resumption apply to HTTP2 / QUIC connection pooling too ? I agree that pooling has some tricky edge cases , but it 's been already deployed as a part of HTTP/2 , so I think we 're currently headed in the direction of working out those cases rather than backing away from the idea altogether . Cross - domain resumption is just extension of cross - domain pooling for cases where the server IP does not match ( and that should not matter from the cryptographic security perspective , since DNS is not cryptographically verified anyways ) . The main source of confusion I am afraid of is when the server starts using SNI from the session cache and ends up using it instead of the new SNI -- which is a problem easily solved by not storing the SNI in it ( -- should I just ban that explicitly ? ) I am somewhat confused by what you mean when you say those things break HSTS and tokbind . The only attack against HSTS that I see in the paper is the one in section 2 -- and it depends on attacker 's ability to send arbitrary headers from the victim domain 's origin . I am not sure how pooling or cross - resumption applies here . Tokbind also should not be problematic -- as long as the entity with the certificate determines backends correctly and routes request to them , all of the requests can only arrive to the respective backends ( also , I should note here that the TLS server in fact has to handle tokbind identification here , since the backends do not have access to the TLS exporter of the session ) . Client certificates are somewhat tricky -- I can imagine some legitimate cases where you 'd want to cross - resume with them , but overall they are more problematic than useful for both pooling and cross - resumption scenarios . I think I 'll just edit the PR and ban cross - resuming if client has presented a cert . 
 any response to ? 
 I personally think this is a good idea . It especially makes sense in the HTTP/2 case if the server has advertised explicit support for the new domain with an ORIGIN frame and the previous connection included the domain in its trust set . 
 Per WG meeting , I think we should add the following text : This matters if the server believes SNI is a per - session property rather than per - connection and does not check equality with the resumption ClientHello value . I know of one popular TLS 1.2 implementation which does this , which is why we ca n't unilaterally offer cross - name resumptions in TLS 1.2 . today . I.e. the client SHOULD needs to be a client MUST in TLS 1.2 . Otherwise , I think this is a good idea . There are clear benefits to cross - name resumption in some scenarios ( same benefits as HTTP/2 cross - name pooling ) . But we should call this out so that implementations which got it wrong in TLS 1.2 do n't continue to get it wrong in TLS 1.3 and mess this up . 
 sorry to bother you but could you please rebase this on top of master . that we we know the merge is the way you want it . 
 I 've reconciled this with changes made in , so that we 're consistent on SNI being per - connection value . I 've some extra descriptive text explicitly calling this out as a change . cc 
 ( I am leaving for the airport now and may not get to look until I 'm back in the US ) 
 I think we probably want to put back some form of : 
 this is already part of the " Client Tracking Prevention " section in " Implementation Notes " you think it should be restated in the " New Session Ticket Message " section ? 
 Maybe a reference to the " Client Tracking Prevention " section would suffice ; I 'll put together a PR .
Paragraph (version B):
Optionally adding, removing, or changing the length of the
"padding" extension RFC7685.
Paragraph (version B):
The parameters for the 0-RTT data (symmetric cipher suite, ALPN
protocol, etc.) are those associated with the PSK in use.  For
externally established PSKs, the associated values are those
provisioned along with the key.  For PSKs established via a
NewSessionTicket message, the associated values are those which were
negotiated in the connection which established the PSK.  The PSK used
to encrypt the early data MUST be the first PSK listed in the
client's "pre_shared_key" extension.
Paragraph (version A):
The TLS version number and cipher suite.
Paragraph (version B):
These requirements are a superset of those needed to perform a 1-RTT
handshake using the PSK in question.  For externally established
PSKs, the associated values are those provisioned along with the key.
For PSKs established via a NewSessionTicket message, the associated
values are those negotiated in the connection during which the ticket
was established.
Paragraph (version B):
In TLS versions prior to TLS 1.3, the Server Name Identification
(SNI) value was intended to be associated with the session (Section 3
of RFC6066), with the server being required to enforce that the SNI
value associated with the session matches the one specified in the
resumption handshake.  However, in reality the implementations were
not consistent on which of two supplied SNI values they would use,
leading to the consistency requirement being de-facto enforced by the
clients.  In TLS 1.3, the SNI value is always explicitly specified in
the resumption handshake, and there is no need to associate an SNI
value with the ticket anymore.
Paragraph (version A):
A set of extension values for the CertificateEntry.  The
"Extension" format is defined in extensions.  Valid extensions
include OCSP Status extensions (RFC6066 and RFC6961) and
SignedCertificateTimestamps (RFC6962).  An extension MUST only be
present in a Certificate message if the corresponding ClientHello
extension was presented in the initial handshake.  If an extension
applies to the entire chain, it SHOULD be included in the first
CertificateEntry.
Paragraph (version B):
A set of extension values for the CertificateEntry.  The
"Extension" format is defined in extensions.  Valid extensions
include OCSP Status extension (RFC6066) and
SignedCertificateTimestamps (RFC6962).  An extension MUST only be
present in a Certificate message if the corresponding ClientHello
extension was presented in the initial handshake.  If an extension
applies to the entire chain, it SHOULD be included in the first
CertificateEntry.
Paragraph (version B):
Note: status_request_v2 extension (RFC6961) is deprecated.  TLS 1.3
servers MUST NOT act upon its presence or information in it when
processing Client Hello, in particular they MUST NOT send the
status_request_v2 extension in the Encrypted Extensions, Certificate
Request or the Certificate messages.  TLS 1.3 servers MUST be able to
process Client Hello messages that include it, as it MAY be sent by
clients that wish to use it in earlier protocol versions.
Paragraph (version B):
The "server_name" RFC6066 and "certificate_authorities" extensions
are used to guide certificate selection.  As servers MAY require
the presence of the "server_name" extension, clients SHOULD send
this extension, when applicable.
Paragraph (version B):
Opening multiple parallel HTTP connections.
Paragraph (version B):
Performing connection racing across interfaces and address
families via, e.g., Happy Eyeballs RFC6555 or related techniques.
Paragraph (version B):
Any ticket MUST only be resumed with a cipher suite that has the same
KDF hash algorithm as that used to establish the original connection.
Paragraph (version B):
Clients MUST only resume if the new SNI value is valid for the server
certificate presented in the original session, and SHOULD only resume
if the SNI value matches the one used in the original session.  The
latter is a performance optimization: normally, there is no reason to
expect that different servers covered by a single certificate would
be able to accept each other's tickets, hence attempting resumption
in that case would waste a single-use ticket.  If such an indication
is provided (externally or by any other means), clients MAY resume
with a different SNI value.
Paragraph (version B):
On resumption, if reporting an SNI value to the calling application,
implementations MUST use the value sent in the resumption ClientHello
rather than the value sent in the previous session.  Note that if a
server implementation declines all PSK identities with different SNI
values, these two values are always the same.
Paragraph (version A):
The presence of padding does not change the overall record size
limitations - the full encoded TLSInnerPlaintext MUST not exceed 2^14
octets.  If the maximum fragment length is reduced, as for example by
the max_fragment_length extension from RFC6066, then the reduced
limit applies to the full plaintext, including the padding.
Paragraph (version B):
The presence of padding does not change the overall record size
limitations - the full encoded TLSInnerPlaintext MUST NOT exceed 2^14
+ 1 octets.  If the maximum fragment length is reduced, as for
example by the max_fragment_length extension from RFC6066, then the
reduced limit applies to the full plaintext, including the content
type and padding.
Paragraph (version A):
Alert messages convey a description of the alert and a legacy field
that conveyed the severity of the message in previous versions of
TLS.  In TLS 1.3, the severity is implicit in the type of alert being
sent, and the 'level' field can safely be ignored.  The
"close_notify" alert is used to indicate orderly closure of the
connection.  Upon receiving such an alert, the TLS implementation
SHOULD indicate end-of-data to the application.
Paragraph (version B):
Alert messages convey a description of the alert and a legacy field
that conveyed the severity of the message in previous versions of
TLS.  In TLS 1.3, the severity is implicit in the type of alert being
sent, and the 'level' field can safely be ignored.  The
"close_notify" alert is used to indicate orderly closure of one
direction of the connection.  Upon receiving such an alert, the TLS
implementation SHOULD indicate end-of-data to the application.
Paragraph (version A):
Either party MAY initiate a close by sending a "close_notify" alert.
Any data received after a closure alert MUST be ignored.  If a
transport-level close is received prior to a "close_notify", the
receiver cannot know that all the data that was sent has been
received.
Paragraph (version A):
If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is
closed, the TLS implementation MUST receive the responding
"close_notify" alert before indicating to the application layer that
the TLS connection has ended.  If the application protocol will not
transfer any additional data but will only close the underlying
transport connection, then the implementation MAY choose to close the
transport without waiting for the responding "close_notify".  No part
of this standard should be taken to dictate the manner in which a
usage profile for TLS manages its data transport, including when
connections are opened or closed.
Paragraph (version A):
Note: It is assumed that closing a connection reliably delivers
pending data before destroying the transport.
Paragraph (version B):
Each party MUST send a "close_notify" alert before closing its write
side of the connection, unless it has already sent some other fatal
alert.  This does not have any effect on its read side of the
connection.  Note that this is a change from versions of TLS prior to
TLS 1.3 in which implementations were required to react to a
"close_notify" by discarding pending writes and sending an immediate
"close_notify" alert of their own.  That previous requirement could
cause truncation in the read side.  Both parties need not wait to
receive a "close_notify" alert before closing their read side of the
connection.
Paragraph (version B):
If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is
closed, the TLS implementation MUST receive a "close_notify" alert
before indicating end-of-data to the application-layer.  No part of
this standard should be taken to dictate the manner in which a usage
profile for TLS manages its data transport, including when
connections are opened or closed.
Paragraph (version B):
Note: It is assumed that closing the write side of a connection
reliably delivers pending data before destroying the transport.
Paragraph (version B):
The Hash function used by Transcript-Hash and HKDF is the cipher
suite hash algorithm.  Hash.length is its output length in bytes.
Messages are the concatenation of the indicated handshake messages,
including the handshake message type and length fields, but not
including record layer headers.  Note that in some cases a zero-
length Context (indicated by "") is passed to HKDF-Expand-Label.  The
Labels specified in this document are all ASCII strings, and do not
include a trailing NUL byte.
Paragraph (version A):
The first class of attack can be prevented by the mechanism described
in this section.  Servers need not permit 0-RTT at all, but those
which do SHOULD implement either the single-use tickets or
ClientHello recording techniques described in the following two
sections.
Paragraph (version A):
In normal operation, clients will not know which, if any, of these
mechanisms servers actually implement and therefore MUST only send
early data which they are willing to have subject to the attacks
described in replay-0rtt.
Paragraph (version B):
The first class of attack can be prevented by sharing state to
guarantee that the 0-RTT data is accepted at most once.  Servers
SHOULD provide that level of replay safety, by implementing one of
the methods described in this section or by equivalent means.  It is
understood, however, that due to operational concerns not all
deployments will maintain state at that level.  Therefore, in normal
operation, clients will not know which, if any, of these mechanisms
servers actually implement and hence MUST only send early data which
they deem safe to be replayed.
Paragraph (version B):
In addition to the direct effects of replays, there is a class of
attacks where even operations normally considered idempotent could be
exploited by a large number of replays (timing attacks, resource
limit exhaustion and others described in replay-0rtt).  Those can be
mitigated by ensuring that every 0-RTT payload can be replayed only a
limited number of times.  The server MUST ensure that any instance of
it (be it a machine, a thread or any other entity within the relevant
serving infrastructure) would accept 0-RTT for the same 0-RTT
handshake at most once; this limits the number of replays to the
number of server instances in the deployment.  Such a guarantee can
be accomplished by locally recording data from recently-received
ClientHellos and rejecting repeats, or by any other method that
provides the same or a stronger guarantee.  The "at most once per
server instance" guarantee is a minimum requirement; servers SHOULD
limit 0-RTT replays further when feasible.