[TLS] encrypted content type and padding
Hey TLS folks-- apologies for the delay in sending these pull requests. encrypted content type: --- https://github.com/tlswg/tls13-spec/pull/51 This should be uncontroversial, and just needed freshening against the current draft. padding: We're now proposing that handshake padding should be offered by introducing a new HandshakePadding message. I've avoided any sort of padding negotiation in the handshake in favor of making padding always available in TLS 1.3 and up. Life is simpler this way. There are two approaches available for application data padding which we failed to select from at Prague (possibly because this is a bikeshed). My preferred approach is to use a standard tls opaque field for application data padding: https://github.com/tlswg/tls13-spec/pull/249 But if anyone is interested, i've also mocked up using a "padding is all 0x00 up to the first 0x01" approach: https://github.com/tlswg/tls13-spec/pull/250 This last approach is unlike anything else in TLS data structures, but it does give the sender the ability to pad with only one octet. There may be a slight sidechannel difference between offsetting by the size of the TLS opaque padding object (PR #249) when compared to running memchr(cleartext, '\001', cleartext_length) (PR #250), but i suspect that timing difference is small compared to the difference incurred by whatever is processing the cleartext (though if the cleartext processor was designed to be constant time itself, the padding timing sidechannel might be noticable). i personally prefer PR #249 because it is more inline with the traditional layout of TLS data elements, and lacks additional risk of timing differences. Its main downside is its inability to pad by anything less than two octets, which slightly complicates calculations of how much to pad when padding algorithmically. See you all in the morning, --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Friday 18 September 2015 15:13:37 Bill Frantz wrote: > On 9/18/15 at 4:27 AM, hka...@redhat.com (Hubert Kario) wrote: > >except that a TLS1.3 version intolerant implementation won't > >show its ugly head until TLS1.4 gets deployed > > Is there a reason a test suite can't offer TLS 1.4, even if we > don't know what it is? There is no reason. In fact, any test suite should basically start with this (it being one of the very first fields the server needs to handle). > The TLS implementation under test should > gracefully step back to TLS 1.3. correct -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Friday 18 September 2015 13:24:33 Brian Smith wrote: > On Fri, Sep 18, 2015 at 4:36 AM, Hubert Kario wrote: > > On Friday 18 September 2015 00:58:19 Martin Rex wrote: > > > Easier troubleshooting is IMO a sufficient rationale to justify > > > existence of the alert mechanism and a "SHOULD send the alert > > > before > > > closing the network connection". > > > > > > A "MUST send fatal alert" requirement, however, would be silly > > > (and > > > will be void in face of rfc2119 section 6 anyway). What would be > > > the semantics of such a requirement anyway? > > > > That's true only if you ignore the situation when TLS 1.4 or TLS 2.0 > > is deployed. > > > So yes, it's no a direct interoperability issue, but it will become > > one > > in the future. > > Given a *conformant* TLS 1.3 implementation, that kind of > interoperability problem could only happen if the TLS working group > specifically designed it to happen. In particular, a conformant TLS > 1.3 implementation must accept larger values of > ClientHello.client_version. Given that there is no *conformant* TLS 1.2 implementation that is widely deployed[1], I won't hold my breath for there being many TLS1.3 ones either. We don't live in ideal world, lets build protocols that can handle breakage. Lets make specifications that have the sticks that we can hit developers with when they do wrong. 1 - NSS, SChannel and OpenSSL, all ignore some MUSTs in TLS1.2 -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt
On Monday 21 September 2015 00:20:21 Dave Garrett wrote: > On Sunday, September 20, 2015 10:59:58 pm William Whyte wrote: > > might be worth increasing the maximum extension size to 2^24-1 for > > TLS 1.3. > No, I don't think the limit can be raised. The general ClientHello > format has to stay frozen for interoperability with other versions, > and unless I'm misreading things, the size of the length of a vector > can't change. A separate message seems like what would be needed to > have a larger first-flight payload. (and any new messages would need > to be signaled via an extension, though it could have a 0-length > payload) we still would need to wait for server to reply before we could send them, so no way to do 1RTT > > Is there a strong reason for keeping the maximum size at 2^24-1, > > other than saving one byte on all the relevant length fields? > > Typo? Did you mean "keeping the maximum size at 2^16-1"? > > A strong reason is it not being possible to change due to the need for > TLS 1.3 clients to be able to connect to TLS 1.2 servers that won't > understand a format change. Even if it were technically possible, I > wouldn't expect all implementations to safely handle it. the TLS1.2 standard says that the ClientHello MUST match either extension-less or an extension-present format and server MUST check that the overall length of message matches the processed data, so we can't have extensions-after-extensions (which theoretically could have 3 byte length field). That limitation is present since RFC 3546 [Extensions], which explicitly says: This overrides the "Forward compatibility note" in [TLS]. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] encrypted content type and padding
On Mon, Sep 21, 2015 at 3:19 AM, Jeffrey Walton wrote: > On Mon, Sep 21, 2015 at 3:02 AM, Daniel Kahn Gillmor > wrote: >> Hey TLS folks-- >> >> apologies for the delay in sending these pull requests. >> >> encrypted content type: >> --- >> >> https://github.com/tlswg/tls13-spec/pull/51 >> >> This should be uncontroversial, and just needed freshening against the >> current draft. > > :) > >> padding: >> >> >> We're now proposing that handshake padding should be offered by >> introducing a new HandshakePadding message. I've avoided any sort of >> padding negotiation in the handshake in favor of making padding always >> available in TLS 1.3 and up. Life is simpler this way. > > Padding can create oracles and complicates proofs. > > When sending data that needs to be padded during key exchange, then > fill it up with random data and digest it in HKDF- like fashion. > > When sending data that needs to be padded during bulk transfer, then > don't do it. Use GCM, CTR, etc. > > Why make life more complicated then it needs to be? Is this actually true in the second pull request? No: a moment of actually reading reveals that the string is inside an AEAD encrypted packet. There is no way in which this padding could be modified for use in a side-channel attack. > > Jeff > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
On Mon, Sep 21, 2015 at 07:38:45AM +0200, Karthikeyan Bhargavan wrote: > > In other words, if we do allow this change to client authentication, > to be safe, we must analyze the resulting protocol *as if* > applications will use the authentication event to attest to all data, > past and present, that may be associated with the data in the current > connection. Under such assumption, even dynamic reauth in HTTP/1.1 is unsafe. If one additionally assumes causality, dynamic reauth in non-pipelined HTTP/1.1 may be safe, but dynamic reauth in HTTP/2 (or HTTP/1.1 with pipelining) is still unsafe. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] WebEx meeting invitation: '15 Fall Interim
Hello, TLS Working Group invites you to join this WebEx meeting. '15 Fall Interim Monday, September 21, 2015 9:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 8 hrs JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=mf2ecbe12f0cf7a93601297ea89cbf5ce Meeting number: 642 106 434 Meeting password: 1234 JOIN BY PHONE 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 642 106 434 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Add this meeting to your calendar: https://ietf.webex.com/ietf/j.php?MTID=m7b586cacef8f6783ed99b91cc96fa0b7 Can't join the meeting? Contact support here: https://ietf.webex.com/ietf/mc IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. WebEx_Meeting.ics Description: Binary data ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] WebEx meeting invitation: '15 Fall Interim
Hello, TLS Working Group invites you to join this WebEx meeting. '15 Fall Interim Tuesday, September 22, 2015 9:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 1 hr JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m3a04aa0bc197fc8e2a2c45b34ac5136b Meeting number: 648 054 164 Meeting password: 1234 JOIN BY PHONE 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 648 054 164 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Add this meeting to your calendar: https://ietf.webex.com/ietf/j.php?MTID=m1402dc79c4de48b304a8ebebc9a0c793 Can't join the meeting? Contact support here: https://ietf.webex.com/ietf/mc IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. WebEx_Meeting.ics Description: Binary data ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fall Interim webex/jabber details
Please note that I sent two webex invites one for each day and that they have different meeting #s but the same pwd: Monday: https://mailarchive.ietf.org/arch/msg/tls/2wD0hlicN7oaBbWO8qKqtXAhfos Tuesday: https://mailarchive.ietf.org/arch/msg/tls/mP16zjy9h7eH2y02WTEnTqDKey4 We’re starting at 9 Pacific Time (fingers crossed). We’ll also be using the tls jabber room: t...@jabber.ietf.org spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
On Sep 21, 2015 7:02 AM, "Ilari Liusvaara" wrote: > Under such assumption, even dynamic reauth in HTTP/1.1 is unsafe. If > one additionally assumes causality, dynamic reauth in non-pipelined > HTTP/1.1 may be safe, but dynamic reauth in HTTP/2 (or HTTP/1.1 with > pipelining) is still unsafe. What do you mean when you say "safe" and "unsafe" here? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
On Sun 2015-09-20 22:38:45 -0700, Karthikeyan Bhargavan wrote: > As dkg points out, dynamically authenticating clients later in the connection > brings up > API issues of how to notify the application about the scope of this new > authentication event. > > I think it is inevitable that implementation will store the client credential > in the session, and > that the new (authenticated) stream of data will be concatenated to the older > (unauthenticated) stream. > Both of these design choices will lead to the following answers to dkg’s > questions: > (a) all messages in TLS sessions (past and present) will be attested to by > every certificate > (b) all traffic in earlier and future resumed sessions will be attested to by > every certificate > > In other words, if we do allow this change to client authentication, to be > safe, we must analyze the > resulting protocol *as if* applications will use the authentication event to > attest to all > data, past and present, that may be associated with the data in the current > connection. But this combination is pretty weird for servers to deal with. For example: Consider a server has an ongoing session wrapped in TLS that uses client authentication to approve or deny some requests from the client. It remembers what requests the client has made as some sort of relevant state. Let's take an imap server working with a client that has state of a "currently-examined folder", but this applies to servers and clients with much more complex state as well. The client is currently examining folder Y. Some client identities *do not* have authorization to visit folder X. others do. The client requests a change to folder X. The server rejects the change. The client subsequently authenticates to an identity that is authorized to access folder X. What is the currently-examined folder for this session? The "easy" (and right) answer here is "folder Y, of course" -- but telling peers that the authentication should apply retroactively to all previous data sent suggests that maybe it should be folder X. This is confusing. Confusing semantics are bound to lead to problematic implementations and usage :( Sorry that this mail doesn't have a better suggestion to offer. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] encrypted content type and padding
On Mon 2015-09-21 04:43:27 -0700, Watson Ladd wrote: > Is this actually true in the second pull request? No: a moment of > actually reading reveals that the string is inside an AEAD encrypted > packet. There is no way in which this padding could be modified for > use in a side-channel attack. In both pull requests, the padding is inside the AEAD encrypted packet. The intent, after all, is to create a mechanism that provides uncertainty about the length of the cleartext. See, for example: I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis by Brad Miller, Ling Huang, A. D. Joseph, and J. D. Tygar http://arxiv.org/abs/1403.0297 --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni wrote: > So the client would now need to cache some session data by transport > address, and other data by name and port. That's rather complex. This is already done by HTTP/2 clients, since they can access multiple servers at the same address:port combination. > And how often will the same client visit multiple servers at the > same transport address? *.github.io, *.blogspot.com, massive CDNs, etc. It's a common pattern. > I don't really see this as viable or worth the effort. I disagree -- the metadata leaked to a passive attacker by mandatory SNI is a valuable signal. It is worth trying to protect it. > I don't think SNI hiding is viable without encryption at the > transport or network layers. any encrypted SNI is effectively acting as a shim for transport encryption, yes. Then again, TLS is itself "transport layer security", so we should try to provide it at least as an option. > And there's still a metadata leak via DNS which may prove difficult to > address. The DNS community is working to address the DNS leak in DPRIVE. The TLS community should be working to fix its own part of the metadata leak. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] '15 TLS WG interim materials
I’ve uploaded the slides I’ve received to: https://www.ietf.org/proceedings/interim/2015/09/21/tls/proceedings.html spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] encrypted content type and padding
On Monday, September 21, 2015 03:02:47 am Daniel Kahn Gillmor wrote: > encrypted content type: > --- > > https://github.com/tlswg/tls13-spec/pull/51 Basing the padding PR(s) on top of this might be a good idea, seeing as it's desired to do this correctly. One thought about doing this with a separate record type, though. It might be better to generalize it by reserving the top bit in the type as a padding flag, thus allowing padding variants of all other types. Record type values would just be the unpadded value plus 128. Implementations could check for padding by simply ANDing a mask to check for the flag. The remaining 7 bits is plenty for the record types field. This could be used for the handshake messages instead of adding a separate handshake padding message. No special type value registration would be needed to add any future padded types. > i personally prefer PR #249 because it is more inline with the > traditional layout of TLS data elements, and lacks additional risk of > timing differences. Its main downside is its inability to pad by > anything less than two octets, which slightly complicates calculations > of how much to pad when padding algorithmically. I agree. Simpler is probably better here. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt
On Monday 21 September 2015 15:04:17 Dave Garrett wrote: > On Monday, September 21, 2015 07:22:03 am Hubert Kario wrote: > > On Monday 21 September 2015 00:20:21 Dave Garrett wrote: > > > A strong reason is it not being possible to change due to the need > > > for TLS 1.3 clients to be able to connect to TLS 1.2 servers that > > > won't understand a format change. Even if it were technically > > > possible, I wouldn't expect all implementations to safely handle > > > it. > > > > the TLS1.2 standard says that the ClientHello MUST match either > > extension-less or an extension-present format and server MUST check > > that the overall length of message matches the processed data, so > > we can't have extensions-after-extensions (which theoretically > > could have 3 byte length field). > > Yeah, adding a second extensions vector in addition to the existing > one was my other thought, but it's too messy for me to think it'd be > worth trying. Looks like that's not even possible. I think we're > stuck with the current TLS extension size limits forever. > > I doubt anyone would really want to use any keys in the megabyte range > anyway. Post-quantum crypto research/experimentation for TLS & other > network protocols should really focus on systems with smaller keys. > Even if a giant-key scheme was ideal, you'll have a very hard time > convincing people to actually use it, no matter how much they might > need it. :/ true, that being said, I can see 64KiB total being limiting for different stuff in the future and while sending 2MiB packets as "just a hello" is unlikely, I can see us sending 64KiB or 128KiB packets... maybe we should reintroduce the forwards compatibility clause for client hello? it won't help us now, but when TLS1.2 gets broken then we'll be able to move forward with higher sizes for extensions (whatever that happens) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
Daniel Kahn Gillmor writes: > Consider a server has an ongoing session wrapped in TLS that uses client > authentication to approve or deny some requests from the client. It > remembers what requests the client has made as some sort of relevant > state. Let's take an imap server working with a client that has state > of a "currently-examined folder", but this applies to servers and > clients with much more complex state as well. ... I think for such a protocol, you'd want to say that authentication is not retroactive. For other protocols, you might want something else. For example, in a protocol which uses client authentication for billing, you might want to treat an authentication half-way through the session as the account to bill for the entire session. Some protocols will also want to support multiple identities, and some will not. For some protocols a new authentication might want to in some fashion dis-trust previous authentications, other protocols might say that all previous authentications are valid until the end of the session. I think this is something that TLS should allow higher-level protocols to specify. The TLS model could be that each client authentication happens at a particular point in the session, breaking it up into segments, and TLS informs the higher-level protocols of where the segments start and end; it's up to the higher-level protocol to work out what that means. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
