attachment
<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <b class="gmail_sendername" dir="auto">Christopher Wood</b> <span dir="ltr"><<a href="mailto:christopherwood07@gmail.com">christopherwood07@gmail.com</a>></span><br>Date: Mon, Apr 1, 2019 at 9:05 AM<br>Subject: [TLS] Minutes from IETF 104<br>To: <<a href="mailto:tls@ietf.org">tls@ietf.org</a>> <<a href="mailto:tls@ietf.org">tls@ietf.org</a>><br></div><br><br>Minutes from last week's TLS meetings in Prague are now online [1].<br>
They're also copied at the end of this message. Please have a look and<br>
send any issues to the list.<br>
<br>
Many thanks to Richard Barnes and Robin Wilton for taking notes!<br>
<br>
Best,<br>
Chris, Joe, and Sean<br>
<br>
[1] <a href="https://datatracker.ietf.org/doc/minutes-104-tls/" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/minutes-104-tls/</a><br>
<br>
-----<br>
<br>
TLS working Group IETF 104<br>
Monday, 25 March, 2019<br>
Prague, CZ<br>
<br>
# Working Group Drafts<br>
<br>
## TLS 1.3 Extension for Certificate-based Authentication with an<br>
External Pre-Shared Key - Russ Housley<br>
<br>
- Draft defines an extension to the TLS handshake, adding an optional<br>
parameter allowing the External PSK to be combined with EC(DHE) as<br>
secret inputs to the key schedule.<br>
<br>
- Watson Ladd: does this enable the sending of early data?<br>
<br>
- RH: No; explicitly stated to be out of scope in the draft.<br>
<br>
- ANO: formal review would be desirable.<br>
<br>
- Ekr: don’t think we should pass this until someone has implemented it.<br>
<br>
- RH: as the first slide notes, this is experimental.<br>
<br>
- one hand in response to question about implementations.<br>
<br>
- * Next Steps: additional review (probably WGLC).<br>
<br>
<br>
# Individual Drafts<br>
<br>
## TLS Resumption across Server Name Indications for TLS 1.3 - Erik Sy<br>
<br>
- TLS 1.3 recommends against, but doesn’t give a good indication of<br>
what criteria to consider, or a signalling mechanism to say if the<br>
server supports Resumption.<br>
<br>
- Performance benefits, CPU time and elapsed time improvements may be<br>
valid criteria - TLS extension would be needed to signal that this<br>
option is available, e.g, a simple flag.<br>
<br>
- Privacy impact could be reduced by enforcing shorter session lengths.<br>
<br>
- Ekr: where should the extension go? - in the EE. Needs to be made<br>
clearer in the doc.<br>
<br>
- Ekr: should also be clear about whether resumption should require a<br>
fresh DNS request<br>
<br>
- Ekr: is a 1-bit flag really sufficient? - yes, otherwise would need<br>
to specify a list of values for which Resumption is OK, and that would<br>
make implementation harder.<br>
<br>
- Ekr: should TLS, in principle, define a general-purpose extension<br>
space rather than a bunch of specific flags?<br>
<br>
- Yoav Nir: 1-bit flag may introduce address space/scope clashes at<br>
the server, and different servers might have different requirements.<br>
Not a good idea to allow reconnection to “any server”. - Server<br>
identification could be aided by reference to the X.509 cert.<br>
<br>
- Viktor: recommends using a session ticket extension for this, not<br>
the handshake itself.<br>
<br>
- Viktor: shortening the acceptable resumption period, as proposed, is<br>
rational, but privacy implications probably need further examination.<br>
- 10 muinutes is a figure of merit.<br>
<br>
- Nick Sullivan: Where an X.509 cert has broad scope (across multiple<br>
servers), additional parameters may be needed to ensure Yoav’s concern<br>
isn’t an issue. Relying only on the -.509 cert makes unreasonable<br>
assumptions.<br>
<br>
<br>
## Importing External PSKs for TLS - Christopher Wood<br>
<br>
- TLS 1.3 imposes restriction on PSK usage with hash functions; TLS<br>
1.2 did not impose this restriction - so the resulting incompatibility<br>
(and potential for inappropriate use of PSKs) must be handled<br>
(ideally) without changing the key schedule.<br>
<br>
- Christian Huitema: working on a draft that generalizes DNS-SD<br>
technique for external PSK identifiers in TLS.<br>
<br>
- Jon Mattsson: question about using one hash algorithm to generate<br>
keys for use with another.<br>
<br>
- ANO: Does the PSK constitute a channel binding? Depending how the<br>
External PSK is generated, this and the Resumption issue may overlap.<br>
A subsequent session has no way of knowing how the previous session<br>
was established.<br>
<br>
- Ekr: reusing hashes as proposed is secure. [Discussion inconclusive,<br>
needs further examination].<br>
<br>
- * No objections to adoption as a work item. Take to list.<br>
<br>
<br>
## TLS Client Network Address Extension - Tommy Pauly<br>
<br>
- Purpose: NAT detection in secure transport protocols<br>
<br>
- Relates to these drafts specifying extensions:<br>
<br>
- TLS, draft-kinnear-tls-client-net-address<br>
<br>
- QUIC, draft-pauly-quic-address-extension<br>
<br>
- Wes H.: is this specific to NATv4? - it applies everywhere.<br>
<br>
- Wes H: Why is this a TLS-specific problem? - for QUIC, this is a<br>
transport handshake question. For TLS, it would be more complicated to<br>
put it elsewhere (?).<br>
<br>
- DKG: what would a client do with this information? - the only real<br>
purpose of this is to check that you’re not behind a NAT.<br>
<br>
- * Discussion moved to the list for timekeeping reasons.<br>
<br>
<br>
## Using Identity as Raw Public Key in Transport Layer Security (TLS)<br>
and Datagram Transport Layer Security (DTLS) - Haiguang Wang<br>
<br>
- Using Identity Based Signature exempts the server from having to<br>
maintain records of the binding between a raw public key and the<br>
entity presenting it.<br>
<br>
- * Next steps: ask to reserve specific code points for this mechanism<br>
to use in implementation and testing.<br>
<br>
<br>
<br>
<br>
Tuesday, 26 March, 2019<br>
<br>
# Working Group Drafts<br>
<br>
## Deprecating TLS 1.0 and 1.1<br>
<br>
- TODO: update to deprecate DTLS 1.0<br>
<br>
- Update to require NNTP to do the right thing<br>
<br>
- * Hearing no objection, headed for WGLC<br>
<br>
<br>
## DTLS 1.3<br>
<br>
- Issue 78 - we will say MUST limit amplification until the path is<br>
validated somehow.<br>
<br>
- - … and we will separately say that though there is a CID, there is<br>
not a migration piece - that is, endpoints don't send to new addresses<br>
in response to receiving valid records from those addresses.<br>
<br>
- Issue 72 - No change.<br>
<br>
- Implementation status - NSS, Mint, mbedTLS.<br>
<br>
<br>
## Cert Compression<br>
<br>
- Add decompressed certificate to transcript? No.<br>
<br>
- * Will write up changes, then WGLC.<br>
<br>
<br>
## Delegated credentials<br>
<br>
- * Ready for LC? Yes, most likely.<br>
<br>
<br>
## ESNI<br>
<br>
- Current solution with PR#137 as an extension? Unclear from the room.<br>
<br>
- Will an ESNI RRType Diverge from the A/AAAA results?<br>
<br>
- [[lots of discussion, no resolutions]]<br>
<br>
<br>
# Individual Drafts<br>
<br>
## OPAQUE in TLS 1.3<br>
<br>
- We should wait for CFRG to opine.<br>
<br>
- Cisco has a use case, some possibility of web API?<br>
<br>
- * No action, due to novelty.<br>
<br>
<br>
## Hybrid key exchange<br>
<br>
- Probably too early, given that research on combinations still active.<br>
<br>
<br>
## CWTs in TLS / DTLS<br>
<br>
- Would need to restrict to PoP tokens.<br>
<br>
- * No action, due to novelty<br>
<br>
<br>
## Fake SNI<br>
<br>
- Should be compared to earlier draft on attacks against SNI approaches.<br>
<br>
- * No action, due to novelty.<br>
<br>
_______________________________________________<br>
TLS mailing list<br>
<a href="mailto:TLS@ietf.org" target="_blank">TLS@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/tls" rel="noreferrer" target="_blank">https://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div>