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