---------- 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>