Re: [TLS] Distinguishing between external/resumption PSKs
On Thu, Sep 19, 2019 at 11:49 PM Nico Williams wrote: > > On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote: > > I don't think anyone's asking for these cases to be differentiable on the > > wire. The question is whether the *server* can differentiate, in > > particular, the application running on the server. > > And the answer to that one is "yes", because the server has control over > the PSK IDs. You are making a lot of implicit assumptions for that. Consider a "server" consisting of multiple front end implementations all connected to a DB back-end. Does that "server" has control over PSK IDs? A server can also be replaced on an upgrade with a different implementation, or a different version of the implementation, does that also guarantee that the server still has control over the PSK IDs? It looks to me like a hard problem to tackle except for few straightforward cases. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A flags extension
On Tue, 2019-03-26 at 10:49 +0100, Yoav Nir wrote:
> > On 26 Mar 2019, at 10:35, Nikos Mavrogiannopoulos
> > wrote:
> >
> > On Tue, 2019-03-26 at 10:11 +0100, Yoav Nir wrote:
> > > > On 26 Mar 2019, at 9:06, Martin Thomson
> > > > wrote:
> > > >
> > > > This needs more space for each flag. 8 bits is a pretty small
> > > > space. If you are concerned with the size of the result, we
> > > > have
> > > > some variable-length integer encodings you could try.
> > >
> > > Ah, the beautiful variable length encodings. Like:
> > >
> > > - 0x00 - 0xBF - for standards-action allocations
> > > - 0xC0,0x00 - 0xEF,0xFF - for non-standards track
> > > - 0xF0,0x00 - 0xFF,0xFF - for private use among consenting
> > > parties.
> > > Are we really worried that we’re going to have more than 255
> > > optional
> > > features for TLS?
> >
> > Given that adding an extended flags extension which can hold even
> > more
> > flags is also easy, the 255-optional features do not seem so
> > limited.
> >
> > Going into the extension itself, the array FlagExtensionType seems
> > to
> > be the TLS-way to define such variable, but flags are easier, more
> > efficient to parse, and take less space if they are bits on an
> > integer
> > value (32-bit or 64-bit). Have you considered a simpler structure
> > like
> > that?
> >
> > struct {
> > uint64 flags;
> > uint64 ext_flags1;
> > uint64 ext_flags2;
> > uint24 ext_flags3;
> > uint16 priv_flags;
> > } Flags;
> >
> > The advantage is that it can carry the same information with much
> > less
> > bytes on the wire and it is easier to parse in low level languages.
> >
> > The disadvantage is that an extension flag would now need to
> > specify
> > the bit it occupies _and_ the particular element it is set to.
>
> I thought about that. I guess it depends on how many of these
> optional features we expect to be declared at the same time.
>
> With the current way the draft is written, if the client supports 12
> such extensions, the extension takes 16 bytes. With a bitstring,
> it’s always the same length. so we’d need 36 bytes for a 256-bit
> space. If the client supports 100 extensions, my encoding takes 104
> bytes while the bitstring is still 36 bytes.
Right. What about defining a set of extensions (e.g., 2 extensions) of
flags as:
struct {
uint64 flags;
} Flags;
That way there are 128 different flags available for assignment with a
cost is 4+8-bytes for every 64 flags.
regards,
Nikos
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A flags extension
On Tue, 2019-03-26 at 10:11 +0100, Yoav Nir wrote:
> > On 26 Mar 2019, at 9:06, Martin Thomson wrote:
> >
> > This needs more space for each flag. 8 bits is a pretty small
> > space. If you are concerned with the size of the result, we have
> > some variable-length integer encodings you could try.
>
> Ah, the beautiful variable length encodings. Like:
>
> - 0x00 - 0xBF - for standards-action allocations
> - 0xC0,0x00 - 0xEF,0xFF - for non-standards track
> - 0xF0,0x00 - 0xFF,0xFF - for private use among consenting parties.
> Are we really worried that we’re going to have more than 255 optional
> features for TLS?
Given that adding an extended flags extension which can hold even more
flags is also easy, the 255-optional features do not seem so limited.
Going into the extension itself, the array FlagExtensionType seems to
be the TLS-way to define such variable, but flags are easier, more
efficient to parse, and take less space if they are bits on an integer
value (32-bit or 64-bit). Have you considered a simpler structure like
that?
struct {
uint64 flags;
uint64 ext_flags1;
uint64 ext_flags2;
uint24 ext_flags3;
uint16 priv_flags;
} Flags;
The advantage is that it can carry the same information with much less
bytes on the wire and it is easier to parse in low level languages.
The disadvantage is that an extension flag would now need to specify
the bit it occupies _and_ the particular element it is set to.
regards,
Nikos
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ticket lifetimes
On Tue, Jan 29, 2019 at 11:53 PM David Benjamin wrote: > On Tue, Jan 29, 2019 at 4:14 PM Subodh Iyengar wrote: > >> > Wouldn't this issue also be mitigated by requiring the server to >> re-authenticate during resumption with the certificate once in a while? >> >> I think it's probably just easier to drop the resumption completely. >> >> > This two-lifetime thing is actually already what we implement in >> BoringSSL. 😊 >> >> Fantastic. Would it help to have an extension to set a lower bound on >> this value, or just make it more painful? >> > > (Did you mean upper bound?) > > I'd actually interpreted the RFC 8446 text to imply a 7 day upper bound on > the renewability, but apparently that's not how others read it! > That was also our understanding in the implementation for gnutls. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] custom lower limit of record_size_limit
On Mon, 2019-01-21 at 16:13 +1100, Martin Thomson wrote: > On Sat, Jan 19, 2019, at 19:02, Daiki Ueno wrote: > > My interpretation is that, if the client sent "record_size_limit" > > but > > didn't receive the extension from the server, that would mean the > > extension was not negotiated and the server may not respect the > > limit. > > > > Is this correct, or 64 is really mandatory to implement? > > Unfortunately, if you want your peer to respect your limit, then you > have to be willing to generate very small records. > > BTW, 64 is entirely an arbitrary number. It's at the point where the > overheads get really noticeable, so performance is probably pretty > bad well before you get to this point. But we didn't get any > indication that it was impossible to go that low. > > If there had been feedback about it being too small, I'm fairly sure > that a large number would have been fine. Do you know why 64 is > considered too hard to implement? I do not think that 64 is not hard to implement, but I think it is very hard to implement it in a way that it is efficient. I have not measured specifically TLS with 64 byte packets, but my experience with ATM (telephony) which has 53-byte packets, suggest to avoid small packetizations if you want use your CPU for something other than packing and unpacking frames. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-dtls-connection-id
On Wed, 2018-11-07 at 14:39 +0700, Joseph Salowey wrote: > This is the working group last call for the "Connection Identifiers > for DTLS 1.2" draft available at > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/. > Please review the document and send your comments to the list by 2359 > UTC on 30 November 2018. > Hi, It is a very good document, I support its publication. Some editorial comments follow. I think the paragraph of the section 3 that starts: "This is effectively the simplest possible design that will work." looks like unnecessary; why would previous designs be mentioned unless there is a challenge for this protocol and in that case an appendix may be more suitable. What about replacing with: "The design is kept simple to ease implementation and deployment" In security considerations the following two paragraphs seem to be part of a single one, that is separated by a However? (i.e., replace Importantly with However), or do I missread it? With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further privacy concerns. Importantly, the sequence number makes it possible for a passive attacker to correlate packets across CID changes. Thus, even if a client/server pair do a rehandshake to change CID, that does not provide much privacy benefit. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
On Mon, 2018-11-05 at 21:24 -0500, Viktor Dukhovni wrote: > TL;DR: Should TLS client abort DHE-RSA handshakes with a peer > certificate that *only* lists: > > X509v3 Key Usage: > Key Encipherment, Data Encipherment > > (which one might take to mean that only RSA key exchange is allowed, > and DHE-RSA is not, for lack of the DigitalSignature bit? > > [ In the unlikely case it matters, the record the certificate > in question is self-signed, and has a DANE TLSA "3 0 1" record. ] > > -- Background: > > I am somewhat sympathetic to forbidding RSA key exchange when > "Key Encipherment" is not listed, in order to reduce the risk of > Bleichenbacher-type attacks, but it is not obvious at first blush > why one might the converse restriction... > > The reason I ask is that the Haskell TLS library has recently added > enforcement in both directions, and I am finding some SMTP servers > with whose STARTTLS implementation my DANE scan engine no longer > interoperates. > > And yet, FWIW, OpenSSL 1.1.1 continues to connect just fine. Is > this an oversight in OpenSSL? Overly strict enforcement in Haskell's > Network.TLS? gnutls has been enforcing that rule for quite some time. That had generated quite some bug reports from application developers in the past. The main argument was, but other implementations work. Nevertheless the last few years the trend has changed and I think that strictness is not only tolerated by developers/end-users but actually promoted. That's only my impression though. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] The TLS WG has placed draft-moriarty-tls-oldversions-diediedie in state "Call For Adoption By WG Issued"
On Fri, 2018-08-17 at 10:33 -0700, IETF Secretariat wrote: > The TLS WG has placed draft-moriarty-tls-oldversions-diediedie in > state > Call For Adoption By WG Issued (entered by Sean Turner) > > The document is available at > https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/ I support the adoption. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-housley-tls-tls13-cert-with-extern-psk
On Mon, 2018-04-23 at 15:30 -0400, Russ Housley wrote: > > > > In the presentation the main driver for it seems to be quantum > > computer > > resistance as temporary measure. If that's the main argument I > > don't > > think it is really significant. PSK can hardly be used with PKI, > > and as > > a matter of fact we use PKI because of PSK key distribution > > problems. > > If we switch to PSK for quantum computer resistance there is there > > a > > reason to use PKI? Probably no (I may be wrong here, if there is a > > reason for a hubrid model I'm missing, I'd be glad to know). > > I am not advocating for a pairwise PSK between every client and > server. If that were available to us, then as you say, we would > always use the PSK without any PKI. > > I envision a PSK being distributed to a group of clients and group of > severs. At some point in the future a large-scale quantum computer > might get invented, and if any member of the group has access to it, > then they can recover the traffic. However, parties outside the > group cannot recover the traffic because the large-scale quantum > computer does not assist with the discovery of the PSK. [going back to this thread, as I have missed that reply and only saw it after the request for adoption was made] It certainly makes sense. > > I could see the main driver for such proposal the replacement of > > the > > RSA-PSK ciphersuites. I know they have _some_ adoption, but I'm not > > sure whether that is significant to require update to TLS1.3. > > This is not my goal. > > > On the implementation side, why not use post-handshake > > authentication > > here? I.e., extend it to be usable from client-side, and on a PSK > > key > > exchange, have the client request server authentication after the > > handshake? > > I'm not sure why that is easier to implement. Can you say more? Current TLS1.3 implementations can do a PSK key exchange and authenticate the client's certificate with post-handshake auth. Based on that, what you'd need to make that authentication two-way (both server and client use cert) is the ability for client to ask the server for certificate. As PHA is fairly simple (server sends a certificate request to client if the PHA extension is seen), doing the opposite if another extension is seen, seems trivial (the bits and pieces are already there). regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WG adoption call: draft-housley-tls-tls13-cert-with-extern-psk
On Thu, 2018-07-26 at 15:05 -0700, Christopher Wood wrote: > The sense of the TLS@IETF102 room was that the WG should adopt > draft-housley-tls-tls13-cert-with-extern-psk as a WG item. This email > is to confirm this sense on list. If you would like for this draft to > become a WG document and you are willing to review it as it moves > through the process, then please let the list know by 2359UTC > 20180809. If you are opposed to this being a WG document, please say > so (and say why). Would it make sense to communicate the reasons of adopting this document by the WG? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
On Thu, 2018-07-26 at 10:58 -0700, Eric Rescorla wrote:
> Ben,
>
> Thanks for focusing on this issue.
>
> Chris and I have been discussing an alternative design which we think
> is more consistent with the existing structure, which we call PSK
> Importers. As with your design, we have an input universal PSK, but
> instead of using explicitly as part of the connection, we just use it
> as the base key to import a set of new PSKs into TLS.
>
> As with Universal PSKs (UPSKs), each input key is a triplet of
> (BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity
> as used today. To use a UPSK, an implementation takes the set of KDF
> hashes it knows about H_i and derives a set of PSKs:
>
> Hash_i: H_i
> Identity_i: BaseIdentity || H_i
> Key_i: Derived from BaseKey and Identity_i
>
> This gives you a set of keys which you can offer simultaneously on
> the
> TLS connection in independent psk_identity blocks. (Note that the
> hash
> algorithm is what differentiates each derived key.) This is a bit
> ugly, but with the current TLS 1.3 ciphers, this basically just means
> SHA-256, but even in the worst case it’s probably only 2-3.
>
> The nice thing about this design is that if you know the set of hash
> functions, you can just compute all the imported PSKs in advance, and
> there’s no need to touch the internals of the TLS stack. This also
> means that if you have decided you don’t like old hash X, you don’t
> need to use it to compute PSK binders, you just use it do the KDF,
> which seems like it has weakersecurity requirements.
>
> Here’s a specific construction, but we’re flexible about the details:
>
>struct {
>opaque base_identity<1...2^16-1>;
>HashAlgorithm hash;
>} imported_psk_identity;
That looks nice, as it allows compatibility with existing psk
implementations.
One improvement could be to have a magic number, to allow easy
disambiguation between an potential existing "raw" (non ascii username
identity), and the new approach.
struct {
opaque magic[4]; // 0x544c0103
HashAlgorithm hash;
opaque base_identity<1...2^16-1>;
} imported_psk_identity;
Such a field will also allow further future improvements to that
approach if needed and allow for incompatible changes in draft versions
as the magic serves as version number.
regards,
Nikos
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
On Fri, 2018-07-20 at 08:42 -0400, David Benjamin wrote: > > > I understand, but as I have already mentioned that argument also > > applies for RSA keys which can be used e.g., for RSA encryption > > under > > TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be > > used > > with multiple hashes under TLS1.2 while only one under TLS1.3. > > TLS 1.3 did not enforce protocol separation for that ugly scenario, > > so > > I wouldn't expect the treatment of PSKs differently. > > PSKs are much easier to fix this with than signing algorithms, given > that we don't want to reprovision either to deploy TLS 1.3. > > ECDSA in TLS didn't get worse with TLS 1.3. We didn't add a new hash > to mixup, just restricted the set from TLS 1.2. If we left it alone, > we'd still have the same effect. For RSA, you're right that we > introduced an extra pair of algorithms to worry about. The options > there are: > > (1) Add PSS, forbid PKCS1, and forbid PSS with id-rsaEncryption. > Cost: TLS 1.3 requires reprovisioning RSA keys. > (2) Add PSS, forbid PKCS1, but allow PSS with id-rsaEncryption. Cost: > We have two algorithms with one key. > (3) Don't forbid PKCS1. Cost: We don't get rid of PKCS#1. > > (1)'s cost is clearly fatal, given 1.3's goals. I'm personally fine > with either (2) or (3), but the WG chose (2). > > With PSKs, I think we can get both. If we consider 1.2 PSKs to be > paired with the 1.2 PRF, we can allocate a new label, and derive a > separate thing to stick in 1.3, and not require reprovisioning. It's > basically free, so I think it makes sense to do it. > (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 > is probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I > don't think we actually believe SHA256 and SHA384 give related > output. It's just nice to avoid the assumption. Whereas TLS1.2-PRF- > SHA256 and HKDF-SHA256 actually a chance of misbehavior. Perhaps it's > worth doing that analysis?) > Of course, I don't actually know what I'm talking about. Opinions > from the formal analysis folks would be great. :-) I wouldn't expect much from formal analysis here, though in the past I've been positively surprised. I'd expect "don't mix algorithms", as with RSA and RSA-PSS. > > Said that, I want to clarify that I wouldn't necessarily object to > > an > > improvement the situation for externally established PSKs. The > > issue I > > see is that TLS1.3 already gives a "good enough" solution with re- > > using > > the key, and I'm afraid we're going to have interoperation issues > > if > > some implementations move to universal psks and some do not, > > defeating > > the purpose of a standard. > > I think that's the point of deciding this immediate question now, so > we can get some text in the specification. If we decide to fix this, > we'd instruct implementations to (temporary!) turn off TLS 1.3 if 1.2 > PSKs are configured and then, once the fixup document is published, > implement it and remove the version logic. This is interoperable at > all combinations as version negotiation runs first. > Personally, I actually don't care much about 1.2 PSKs as I don't work > with anything that uses them. I do care about allowing new protocols > to use 1.3 external PSKs cleanly---new protocols can just mandate 1.3 > and avoid 1.2, but the hash rule makes the whole thing unusable and > it is unclear whether 1.3 PSKs will be usable in a future 1.4. I > figured it'd be easy to patch the 1.2 issue while I was at it, thus > the construction in my draft. > > But the exact derivation can be worked out separately, my draft or > not. The immediate question is whether we think 1.2 PSKs should be > reusable in 1.3 as-is or whether we should stick a derivation step to > separate them. The derivation makes sense to be part of the draft. It makes sense to me the whole draft to be part or referred from TLS1.3. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote: > > > > > This is somewhat timely, as if we do want to introduce a > > restriction, > > > it > > > would ideally be in the form of some text in the TLS 1.3 > > > specification, > > > which is very nearly done. > > > > > > It would be good to hear more opinions on this question, > > particularly > > > from those who have worked on the formal verification directly. > > > > > > If I can attempt to summarize some discussion that occurred in > > the > > > mic > > > line today, Hannes was surprised that we would care, likening > > this > > > case > > > to the regular version negotiation, where we are happy to use the > > > same > > > certificate to sign messages for both TLS 1.2 and 1.3. David > > > Benjamin > > > points out that we explicitly go to the trouble of putting 64 > > bytes > > > of > > > 0x20 padding at the front of the content that gets signed for > > > CertificateVerify, to enforce separation between the TLS > > versions. > > > > > > My own personal opinion is that we should enforce a domain > > separation > > > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's > > "Universal > > > PSKs" > > > proposal seems like a potential mechanism by which to do so > > without > > > doubling the provisioning needs. > > > > I think the same rules should apply for PSK and RSA/ECDSA/EdDSA > > keys. > > There is no inherent difference between the two keys types. I could > > have deployed TLS with PKI or TLS with PSK. I should be able to > > upgrade > > protocols the same way. > > > > If RSA keys can be re-used between TLS1.2 and TLS1.3, then so > > should > > PSK keys. The current document specifically allows that re-use, and > > if > > you fear that the current document did not take cross-protocol > > attacks > > in mind during design, then let's fix that instead. > > The issue is not cross-protocol attacks; it's the reuse of PSKs with > different KDFs, which we don't have any analysis for I understand, but as I have already mentioned that argument also applies for RSA keys which can be used e.g., for RSA encryption under TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be used with multiple hashes under TLS1.2 while only one under TLS1.3. TLS 1.3 did not enforce protocol separation for that ugly scenario, so I wouldn't expect the treatment of PSKs differently. Said that, I want to clarify that I wouldn't necessarily object to an improvement the situation for externally established PSKs. The issue I see is that TLS1.3 already gives a "good enough" solution with re-using the key, and I'm afraid we're going to have interoperation issues if some implementations move to universal psks and some do not, defeating the purpose of a standard. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
On Thu, 2018-07-19 at 18:00 -0500, Benjamin Kaduk wrote: > Hi all, > > As I mentioned at the mic today, there is a question that has been > raised about whether it's wise to reuse an existing (TLS 1.2) PSK > directly in the TLS 1.3 key ladder. At a high level, the reason why > one > might want to restrict this is that the security proofs for TLS 1.3 > rely > on the pre-shared key being only used with a single key-derivation > function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different > key-derivation function, so formally the proofs do not hold. We > don't > currently know of a specifc attack against such reuse, of course, but > perhaps it is prudent to restrict our usage to adhere to the verified > scenarios. > > This is somewhat timely, as if we do want to introduce a restriction, > it > would ideally be in the form of some text in the TLS 1.3 > specification, > which is very nearly done. > > It would be good to hear more opinions on this question, particularly > from those who have worked on the formal verification directly. > > If I can attempt to summarize some discussion that occurred in the > mic > line today, Hannes was surprised that we would care, likening this > case > to the regular version negotiation, where we are happy to use the > same > certificate to sign messages for both TLS 1.2 and 1.3. David > Benjamin > points out that we explicitly go to the trouble of putting 64 bytes > of > 0x20 padding at the front of the content that gets signed for > CertificateVerify, to enforce separation between the TLS versions. > > My own personal opinion is that we should enforce a domain separation > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal > PSKs" > proposal seems like a potential mechanism by which to do so without > doubling the provisioning needs. I think the same rules should apply for PSK and RSA/ECDSA/EdDSA keys. There is no inherent difference between the two keys types. I could have deployed TLS with PKI or TLS with PSK. I should be able to upgrade protocols the same way. If RSA keys can be re-used between TLS1.2 and TLS1.3, then so should PSK keys. The current document specifically allows that re-use, and if you fear that the current document did not take cross-protocol attacks in mind during design, then let's fix that instead. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Broken browser behaviour with SCADA TLS
On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote: > On Wed, Jul 04, 2018 at 07:57:41AM +, Peter Gutmann wrote: > > Ilari Liusvaara writes: > > > > > More serious problem is servers returning too small modulus due > > > lack of > > > negotiation. Which was the reason why Chrome disabled DHE. > > > > Why not reject the handshake if the modulus is too small, rather > > than > > disabling all DHE suites on the off chance that the server returns > > a value you > > don't like? > > Chrome initially did that. It caused quite a lot of bad feedback from > owners of various bad embedded stuff. The thread on relevant forums > was > quite something. Hundreds of messages blaming Google for breaking > stuff. We had similar experience when we required a minimum of 2048-bit modulus for all TLS connections in Fedora 28 beta irrespective of back- end lib. It broke connections to VPN servers and web internal web sites and we had to revert the change. The DHE ciphersuites under TLS1.2 seem doomed and rfc7919 couldn't save them. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Universal PSKs
On Mon, 2018-06-18 at 13:56 +0200, Jonathan Hoyland wrote: > The issue with the current draft is that it leaves a single PSK with > two potential interpretations. > If the draft also changed the PSK identity value then each PSK would > have a single interpretation. > If the draft changes the identity then it can also change the PSK key > without having to change the manner in which the binder is computed. > In that case universal PSKs and regular PSKs do not need to be > distinguished, because they are both validated in the same way. > > A server unaware of universal PSKs would simply see an unrecognised > PSK identity. > If both the unmodified and the modified PSKs are sent, then it can > simply select the unmodified version, ignoring the other. > A server that recognises both values can choose which to use. > > If the modified PSK identity was a channel binding, then the modified > version would have stronger security properties, and thus presumably > would be preferable. > In this case the hash function used for the binder remains > selectable. > > Would that resolve your issue? That may not be sufficient. A server which sees an unrecognized PSK may chose to pretend it recognized it to avoid user enumeration attacks similarly to TLS1.2 (optional) behavior. Hence a modified username would cause negotiation failure with such a server. A new extension seems to be necessary to eliminate any interoperability issues with servers that will not follow the universal psk draft. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Universal PSKs
On Fri, 2018-06-15 at 13:00 +0100, Matt Caswell wrote: > > On 15/06/18 12:37, Nikos Mavrogiannopoulos wrote: > > It feels that's this is too little too late. Implementations which > > support PSKs will switch to TLS1.3 irrespective of this proposal. > > If > > this proposal takes on, we will have some implementations which > > support > > universal PSKs and others which don't leading to interoperability > > problems which we wouldn't have otherwise. > > I'm not sure how many TLS1.3 implementations there are out there that > also have TLS1.2 PSK support. OpenSSL is one of them. We have APIs > for TLS1.2 PSKs and different APIs for TLS1.3 PSKs. Currently > applications > using the old APIs can still expect those PSKs to work in TLS1.3. In > light of this proposal we are considering removing our TLS1.2 -> > TLS1.3 > PSK code and instead restricting applications using TLS1.2 PSK APIs > to > only TLS1.2 until this is resolved (although unfortunately that would > mean removing it from our upcoming LTS release). In gnutls [0] we have the same APIs for PSK under TLS1.2 and TLS1.3 and the transition is quite smooth, but in contrast to David's algorithm, we select a PSK before selecting the ciphersuite in order to make that work. The problem I see is that PSKs are restricted to SHA256 KDF and thus AES128 which is somewhat ugly but we can live with it until we provide a better way to mark a specific PRF in our key files. regards, Nikos [0]. https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html (PSK key exchange) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Universal PSKs
On Fri, 2018-06-15 at 09:11 -0400, David Benjamin wrote: > On Fri, Jun 15, 2018 at 7:14 AM Hubert Kario > wrote: > > On Thursday, 14 June 2018 21:46:27 CEST David Benjamin wrote: > > > Thoughts? If the WG likes this design, I would suggest: > > > > > > - Most folks who want to use TLS 1.3 with external PSKs should > > probably > > > design their protocols to provision universal PSKs instead, after > > it > > > stabilizes. > > > > > > - Folks who want to use TLS 1.3 with existing TLS 1.2 PSKs should > > use the > > > compatibility derivation in this draft, after it stabilizes. > > > > > > - Folks who want to ship TLS 1.3 before then and have a TLS 1.2 > > PSK API > > > should not use the 1.2 PSK as a 1.3 PSK. For now, just turn TLS > > 1.3 off by > > > default if that API is used and, in a future release, use the > > compatibility > > > derivation after it stabilizes. > > > > that's not workable. > > > > the reason why implementations chose to use old API to provision > > TLS 1.3 PSKs > > was to make the upgrade process as smooth as possible, disabling > > TLS 1.3 is > > quite antithetical to that > > Indeed. That is why the TLS 1.2 compatibility section exists. :-) So > that implementations in that position can reuse TLS 1.2 PSK APIs in > TLS 1.3 while honoring the security proof. > > But, unfortunately, there's a slight timing issue. There's no way > some random draft published yesterday will be finalized before TLS > 1.3. So implementations with TLS 1.2 PSK APIs would need to either > violate the TLS 1.3 security proof or not ship TLS 1.3 until this > draft finalizes. Is key separation between TLS1.3 and TLS1.2 something that TLS1.3 provides or intended to provide? As I mentioned in my reply TLS1.3 design goals were very apparent that keys will be re-used from TLS1.2, and this is what is happening today for any kind of keys from RSA to PSKs. I'm not sure I see a new cross-protocol violation here that was not discussed during the TLS1.3 process. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Universal PSKs
On Fri, 2018-06-15 at 14:24 +, Salz, Rich wrote: > >that's not workable. > > > It's not great, however > > >the reason why implementations chose to use old API to provision > > TLS 1.3 PSKs > > was to make the upgrade process as smooth as possible, disabling > TLS 1.3 is > quite antithetical to that > > Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect > most uses, and seems the only way forward. > > Do you have an alternative solution? TLS 1.3 provides a solution. These secrets under TLS1.3 are restricted to using the SHA256 PRF. That's how we have implemented it in gnutls. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] cost of padding removal in TLS1.3 [was: Possible timing attack on TLS 1.3 padding mechanism]
On Thu, 2018-03-01 at 21:52 +, Paterson, Kenny wrote: > Hi, > > I've been analysing the record protocol spec for TLS 1.3 a bit, > specifically the new padding mechanism. I think there's a possible > timing attack on a naïve implementation of de-padding. Maybe this is > already known to people who've been paying more attention than me! > > Recall that the padding mechanism permits an arbitrary number of 00 > bytes to be added after the plaintext and content type byte, up to > the max record size. This data is then encrypted using whichever AEAD > scheme is specified in the cipher suite. This padding scheme is quite > important for TLS 1.3 because the current AEAD schemes do leak the > length of record plaintexts. There should be no padding oracle style > attack possible because of the integrity guarantees of the AEAD > schemes in use. > > The idea for the timing attack is as follows. > > The natural way to depad (after AEAD decryption) is to remove the 00 > bytes at the end of the plaintext structure one by one, until a non- > 00 byte is encountered. This is then the content type byte. Notice > that the amount of time needed to execute this depadding routine > would be proportional to the number of padding bytes. If there's some > kind of response record for this record, then measuring the time > taken from reception of the target record to the appearance of the > response record can be used to infer information about the amount of > padding, and thereby, the true length of the plaintext (since the > length of the padded plaintext is known from the ciphertext length). Hi, I'd like to get back into that old thread because we've figured out that making the padding removal not depending on the data is quite costly for aes-gcm on a modern processor. Roughly, the record processing time drops by half for large packets comparing to TLS1.2, in effect pushing implementors to make the default padding removal time- variable. Has this performance drop been observed by others? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Universal PSKs
On Thu, 2018-06-14 at 15:46 -0400, David Benjamin wrote: > Hey all, > > So TLS 1.2 has a mechanism for PSKs. We attempted to mirror it in TLS > 1.3 via the external PSK mechanism, repurposing the resumption flow. > But the security proof requires PSKs be associated with a specific > hash for key separation. We use distinguishing labels in the key > schedule, but if that key is fed into a completely different KDF, > analysis must additionally consider interactions between the KDFs. > > The hash constraint, however, makes it difficult to actually use > external PSKs in applications. Usually the TLS stack and its > configuration evolves somewhat independently from the calling > application. But now the PSK provisioning process must short-circuit > part of the TLS parameter negotiation, despite it likely being > implemented in a separate library altogether. This is a leaky > abstraction. > > It also complicates server parameter selection. We've found the > cleanest algorithm is selecting the cipher suite first, and then > ignoring the PSKs that don't match. This is simple and avoids weird > behavior if a session is renewed across preference changes. However, > this only works for resumption PSK: if the session mismatches, a full > handshake is always an option. With external PSKs, the application > usually expects the PSK to be mandatory. > Finally, some libraries (e.g. OpenSSL) already TLS 1.2 PSK APIs and > wish to transparently upgrade to TLS 1.3. The specification does not > explicitly say if a TLS 1.2 PSK may be used directly as a TLS 1.3 PSK > and I believe some implementations are doing that. However that > violates TLS 1.3's key separation assumptions in the same way as > mixing hashes: the TLS 1.2 PRF is not the same as HKDF. I don't think that TLS1.3 has strict key separation assumptions, and they are nowhere spelled out. For example, RSA keys can be used for RSA-PSS or RSA PKCS#1 1.5 signatures or RSA encryption. > It's a bit late to completely redo external PSKs in 1.3, but I > believe we can fix this in a separate draft. The draft below proposes > "universal PSKs" which derive independent hash- and version-specific > secrets for TLS 1.3 (and later) as needed. For existing TLS 1.2 PSKs, > it includes a compatibility derivation to go from TLS 1.2 PSKs to > universal PSKs. > > (Thanks to Karthikeyan Bhargavan, Matt Caswell, Eric Rescorla, and > Victor Vasiliev for discussions which led to this design. Any > mistakes in it are mine.) > > Thoughts? It feels that's this is too little too late. Implementations which support PSKs will switch to TLS1.3 irrespective of this proposal. If this proposal takes on, we will have some implementations which support universal PSKs and others which don't leading to interoperability problems which we wouldn't have otherwise. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 multiple session tickets from the client?
On Wed, 2018-05-16 at 11:30 +0200, Ander Juaristi wrote: > El 2018-05-11 09:05, Nikos Mavrogiannopoulos escribió: > > On Thu, 2018-05-10 at 11:46 -0400, Viktor Dukhovni wrote: > > > > > > Good to know. Does any implementation other than OpenSSL support > > > external PSKs? How do you distinguish between external PSKs and > > > resumption PSKs? > > > > gnutls does. For external PSKs It checks for ticket age being zero > > and > > the username/identity within acceptable bounds. > > Hey Nikos, > > I remember we had this discussion, but wanted to transfer it to the > list > as even though I believe that approach > will work almost always, by reading the current draft my > understanding > is that being the ticket age zero is no more than a hint > that it *might* be a PSK. > > What's wrong with trying to decrypt it first and then if decryption > fails treat it as an external PSK and look up > its identity in the database? GnuTLS encrypts the tickets with EtA > so > with "decrypt" I mean checking the MAC first, > and then decrypting. Isn't this a stronger check? Decrypting a ticket may not always be possible. For example, server keys may get rotated, or a server may receive key which were destined for another server in the pool. > Another option to remove some ambiguity out of here would just be to > change the draft to say that externally set PSKs > MUST have a ticket age of zero (rather than SHOULD). This way a > server > can instantly recognize an external PSK. A real > ticket can never have an obfuscated ticket age of zero, right? Or it > can? I think that ticket age could be zero even for non-preshared keys (not very likely though). A field which could potentially be used to distinguish tickets is the key_name of an rfc5077 formatted ticket. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 multiple session tickets from the client?
On Thu, 2018-05-10 at 11:46 -0400, Viktor Dukhovni wrote: > > On May 10, 2018, at 10:17 AM, Eric Rescorla wrote: > > > > > Do you prepend some new "magic" to the (RFC5077 or similar) > > > session > > > tickets? Or just look for a matching STEK key name and let that > > > be > > > the "magic"? > > > > I would imagine, but NSS, at least, doesn't support external PSKs. > > Good to know. Does any implementation other than OpenSSL support > external PSKs? How do you distinguish between external PSKs and > resumption PSKs? gnutls does. For external PSKs It checks for ticket age being zero and the username/identity within acceptable bounds. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator
On Thu, 2018-04-19 at 16:32 -0400, Sean Turner wrote: > All, > > This is the working group last call for the "Exported Authenticators > in TLS" draft available at https://datatracker.ietf.org/doc/draft-iet > f-tls-exported-authenticator/. Please review the document and send > your comments to the list by 2359 UTC on 4 April 2018. I have not checked the mechanism, but I have few questions based on the description in the introduction. "Post-handshake authentication is defined in TLS 1.3, but it has the disadvantage of requiring additional state to be stored in the TLS state machine and it composes poorly with multiplexed connection protocols like HTTP/2. It is also only available for client authentication. This mechanism is intended to be used as part of a replacement for post-handshake authentication in applications." * Was this proposed to be included in TLS 1.3 as post-handshake authentication mechanism instead? * What are the actual problems that post-handshake authentication has with HTTP/2? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-housley-tls-tls13-cert-with-extern-psk
On Wed, 2018-04-18 at 12:25 -0400, Russ Housley wrote: > In London, I was on the agenda to talk about certificate-based > authentication with external pre-shared key (PSK). We ran out of > time, and I did not get to make the presentation. The slides are in > the proceedings; see https://datatracker.ietf.org/meeting/101/materia > ls/slides-101-tls-sessa-certificate-based-authentication-with- > external-psk-00. > > Please review the document and send comments to the list. > > I would like the TLS WG to adopt this document. In the presentation the main driver for it seems to be quantum computer resistance as temporary measure. If that's the main argument I don't think it is really significant. PSK can hardly be used with PKI, and as a matter of fact we use PKI because of PSK key distribution problems. If we switch to PSK for quantum computer resistance there is there a reason to use PKI? Probably no (I may be wrong here, if there is a reason for a hubrid model I'm missing, I'd be glad to know). I could see the main driver for such proposal the replacement of the RSA-PSK ciphersuites. I know they have _some_ adoption, but I'm not sure whether that is significant to require update to TLS1.3. On the implementation side, why not use post-handshake authentication here? I.e., extend it to be usable from client-side, and on a PSK key exchange, have the client request server authentication after the handshake? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration
On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote: > On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote: > > > > > > On 3/15/2018 5:51 PM, Benjamin Kaduk wrote: > > > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote: > > > ... > > > > we do not have a reliable mechanism of differentiating between > > > > external and > > > > resumption PSKs while parsing Client Hello > > > > > > Well, a valid external PSK (identity) the server will of course > > > recognize, and we have a SHOULD-level requirement that the > > > obfuscated_ticket_age is zero for external PSKs. I haven't > > > gotten > > > to think through whether there is still potential for information > > > leakage about external PSK identities, but it seems like there > > > would > > > not be, provided that the server prefers resumption to external- > > > PSK > > > full handshakes. > > > > > > > I am concerned with the privacy issues linked to these "external > > PSK > > identities". If a system is set so that clients use static PSK > > identities, then the identity is an identifier and the client's > > movements and connections can be tracked. I don't think privacy is > > improved if we make it easy to differentiate external identities > > from > > resumption tickets. > > Oh, of course, the privacy considerations of the current external > PSK scheme are terrible! This follows naturally from external PSKs > having not really been a first-class citizen while we were designing > things; we stuffed resumption PSKs together with external PSKs for > the convenience of having them use the same binder construct and > only needing to have one extension at the end of the ClientHello. > Resumption flows get single-use tickets for privacy preservation, > and external PSKs get infinite use and a gigantic correlation > channel. I agree. > > If you want to use PSK with some level of privacy, you might adopt > > a > > different setup. For example, servers could provision the clients > > with a > > set of single-use external PSK identities. But then, that looks a > > lot > > like resumption. Or, clients could generate single-use external PSK > > identities by encrypting their long term identity and a nonce with > > the > > public key of the server, a design which of course has its own set > > of > > issues. > > > > But, as you note, this is something of an open problem for how to do > well, and this document is already approved by the IESG. (It's also > not entirely clear that the TLS WG would be the best place to design > this sort of scheme, though of course it could choose to do so.) > > So to me the open question is whether we consider enumeration of > external PSK identifiers to be something we can address reasonably > at this stage of the document's lifecycle at all. (I also note that > the presence of a CVE number for a similar issue does not > necessarily mean anything -- CVE assignments can occur for > situations with no actual security impact and/or against the wishes > of the software authors.) I don't think anyone has proposed a > minimal change that would close the enumeration channel, and given > that external PSKs already have bad privacy properties, it seems > like we may just have to accept this state of affairs for this > document. That's a good general remark, but not really the case for the vulnerabilities that Hubert pointed out. > Hubert also says: > > % so there's no reliable way to say that, yes, this identity is or is > not a > % resumption ticket, if I can't decrypt it > > Mostly. External PSKs are established out of band, and that > provisioning process *could* include knowledge that the > obfuscated_ticket_age would always be zero when those PSKs are in > use, and that would be reliable for those specific parties. I believe that this can happen in an interoperable way if the protocol mandates it (which is not the case now). These specific parties may use software from different vendors which may use different conventions if the protocol is not clear enough. > It's probably also worth considering the two cases for server > behavior when presented with a PSK id that is neither a known > external PSK nor a known resumption ticket -- the server could > either treat it as an unknown external PSK id or as a resumption > ticket that fails to decrypt. The latter case fails because the > attacker can try candidate external identities and the server falls > back to a full handshake unless the PSK ID is good. (Well, maybe > the server rejects PSK IDs that are shorter than a ticket would be.) > The first case is not really usable since it would lead to spurious > triggering of the proposed "at most one external PSK" check. > > So, in addition to the "we provision external PSKs only when we know > that obfuscated_ticket_age will be zero", deployments could also > agree that external PSK ids are shorter than a given length and > resumption PSKs are larger, which would again provide a reliable > di
Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism
On Thu, 2018-03-01 at 21:52 +, Paterson, Kenny wrote: > Hi, > > I've been analysing the record protocol spec for TLS 1.3 a bit, > specifically the new padding mechanism. I think there's a possible > timing attack on a naïve implementation of de-padding. Maybe this is > already known to people who've been paying more attention than me! > > Recall that the padding mechanism permits an arbitrary number of 00 > bytes to be added after the plaintext and content type byte, up to > the max record size. This data is then encrypted using whichever AEAD > scheme is specified in the cipher suite. This padding scheme is quite > important for TLS 1.3 because the current AEAD schemes do leak the > length of record plaintexts. There should be no padding oracle style > attack possible because of the integrity guarantees of the AEAD > schemes in use. > > The idea for the timing attack is as follows. > > The natural way to depad (after AEAD decryption) is to remove the 00 > bytes at the end of the plaintext structure one by one, until a non- > 00 byte is encountered. This is then the content type byte. Notice > that the amount of time needed to execute this depadding routine > would be proportional to the number of padding bytes. If there's some > kind of response record for this record, then measuring the time > taken from reception of the target record to the appearance of the > response record can be used to infer information about the amount of > padding, and thereby, the true length of the plaintext (since the > length of the padded plaintext is known from the ciphertext length). > > The timing differences here would be small. But they could be > amplified by various techniques. For example, the cumulative timing > difference over many records could allow leakage of the sum of the > true plaintext lengths. Think of a client browser fetching a simple > webpage from a browser. The page is split over many TLS records, each > of which is individually padded, with the next GET request from the > client being the "response record". (This is a pretty simplistic view > of how a web browser works, I know!). The total timing difference > might then be sufficient for webpage fingerprinting, for example. > > I'm not claiming this is a big issue, but maybe something worth > thinking about and addressing in the TLS 1.3 spec. > > There's at least a couple of ways to avoid the problem: > > 1. Do constant-time depadding - by examining every byte in the > plaintext structure even after the first non-00 byte is encountered. > 2. Add an explicit padding length field at the end of the plaintext > structure, and removing padding without checking its contents. (This > should be safe because of the AEAD integrity guarantees.) > > Option 2 is probably a bit invasive at this late stage in the > specification process. Maybe a sentence or two on option 1 could be > added to the spec. Hi, It was brought previously to the WG [0], and the bottom line was to push for any solution to implementations. As of the "naïve implementation of de-padding", I wouldn't put like that. It is a straightforward method of de-padding after reading the draft, and I believe all implementations out there use that method. regards, Nikos [0]. https://www.ietf.org/mail-archive/web/tls/current/msg24365.html ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity
On Thu, 2018-03-01 at 10:49 -0500, David A. Cooper wrote: > > I believe you are misinterpreting the text, but agree that it could > be > made more clear. > > Suppose that the ClientHello includes a supported_versions > extensions > that contains two values, TLS 1.4 and TLS 1.0, and the server > supports > TLS 1.3 and below. My interpretation of the current draft is that > the > server MUST use the supported_versions extension to determine the > client's preference, but then once deciding to use TLS 1.0 for the > connection sends a normal TLS 1.0 ServerHello, with version field set > to > 0x0300 and no supported_versions extension. Note that Section 4.2.1 > says > that > > A server which negotiates TLS 1.3 MUST respond by sending a > "supported_versions" extension containing the selected version > value (0x0304). > > It says nothing about a server that negotiates an earlier version. > > If my understanding is correct, then I believe the text in Section > 4.1.3 > could be made more clear. Draft -21 said that the version field of > ServerHello "contains the version of TLS negotiated for this > connection." (this is similar to what RFC 5246 said). The current > draft > says: > >In TLS 1.3, the TLS server indicates its version using the >"supported_versions" extension (Section 4.2.1), and the >legacy_version field MUST be set to 0x0303, which is the >version number for TLS 1.2. > > To be consistent with RFC 5246 and earlier, it seems like the text > should say something like: > >For a TLS 1.3 ServerHello the TLS server indicates its version >using the "supported_versions" extension (Section 4.2.1), and >the legacy_version field MUST be set to 0x0303, which is the >version number for TLS 1.2. For a TLS 1.2 and earlier > ServerHello >the legacy_version field contains the version of TLS > negotiated >for this connection. I understand that this is an interpretation that makes more sense and aligns with the -21 behavior, but I do not think that this is what this text literally says. Both Eric in his previous email and another engineer I've discussed the issue seem to agree that the intention is to use the new mechanism for all negotiations. You disagree on that, and it thus apparent that this text needs clarification. The text was written for -21 version which didn't have the server-side part of the extension, and the flow was natural for pre-TLS1.3 versions. When the change was done in -22 to include the server-side of the extension, this ambiguity (in your view) and complicated side- effect (in my view) was introduced. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] draft-ietf-tls-tls13-24 supported_versions complexity
The TLS draft after version -21 requires TLS1.3 servers to negotiate pre-TLS1.3 versions with a new, mechanism. The document states: "If this extension is present, servers MUST ignore the ClientHello.legacy_version value and MUST use only the "supported_versions" extension to determine client preferences." ... "Note that this mechanism makes it possible to negotiate a version prior to TLS 1.2 if one side supports a sparse range." At this point, a server receiving a supported_versions extension which contains the single value 'TLS 1.0' has to follow the draft's recommendations and do: 1. It MUST set the ServerHello.legacy_version field to 0x0303 (TLS 1.2). 2. On the serverHello extensions include a supported_versions extension and advertise TLS1.0 That modifies the way TLS 1.1 or TLS 1.0 are negotiated, possibly introducing new issues with middle-boxes which see TLS1.2 in the ServerHello but TLS1.0 anywhere else. That is also a quite impossible code path (why would an implementation negotiate TLS1.0 using a TLS1.3 mechanism?). It is however anticipated to be used for that purpose as this draft mentions: "Servers should be prepared to receive ClientHellos that include this extension but do not include 0x0304 in the list of versions." Irrespective to any middle-box issues, I believe impossible code paths allowed by the protocol are more likely to cause problems than solve any, because they are often not tested, and provide attackers with additional tools to manipulate implementations. My recommendation to address that would to either ignore that extension if pre-TLS1.2 is negotiated, or revert to -21 draft behavior for pre- TLS1.3 protocol negotiation. That is, the server MUST not send the supported_versions extension if a pre-TLS1.3 protocol is to be negotiated. The first case ensures that there is a single way to negotiate TLS1.x, where x<3, and the second that the clientHello extension is only used informatively. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Multiple records in record limit (was: Secdir review)
On Mon, 2018-02-26 at 12:39 +1100, Martin Thomson wrote: > Out of the secdir review (thanks again Alan!), I realized that the > draft never actually said this: > >PMTU governs the size of UDP datagrams, which limits the size of > records, but >does not prevent records from being smaller. An endpoint that > sends small >records is still able to send multiple records in a single UDP > datagram. > > I think that I should add that explanation. > > Does anyone think that this should go further and advise against > putting multiple records in the same datagram? I'm not sure which part of the protocol text this would refer to, but DTLS1.2 says in https://tools.ietf.org/html/rfc6347#section-4.1.1 ``` Multiple DTLS records may be placed in a single datagram. They are simply encoded consecutively. ``` so even though I agree that the advice against putting multiple records in the same datagram is a good one (I'm not even sure if that works today with existing implementations), the advice seems against the original protocol. Shouldn't that text be in the upcoming DTLS1.3 rather than an update like record size limit which seems unrelated? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS
On Fri, Dec 15, 2017 at 2:01 AM, Hanno Böck wrote: > On Thu, 14 Dec 2017 16:45:57 -0800 > Colm MacCárthaigh wrote: > > > But what would that look like? What would we do now, in advance, to > > make it easy to turn off AES? For example. > > I think this is the wrong way to look at it. > > From what I'm aware nobody is really concerned about the security of > AES. I don't think that there's any need to prepare for turning off AES. > > The problem with PKCS #1 v1.5 is that it survived so long *after* its > was known that it was bad. I really recommend everyone who wants to > know how protocols go bad to read up on the Bleichenbacher > countermeasures in TLS 1.0, 1.1 and 1.2 - and particularly the last > one. The chapter in 1.2 is a nightmare and I seriously fail to > understand how anyone could have seen that and think it's a good idea > to do that in order to stay compatible with a standard that was already > deprecated at that point. > > We know that when this group decided to deprecate both PKCS #1 1.5 and > RSA encryption that there were people trying to lobby against that. I'm > glad that this wasn't successful. > RSA PKCS #1 1.5 decryption and signatures are far from deprecated. In fact the security of TLS 1.3 is heavily tied to these primitives if servers support TLS 1.2 and RSA (see [0]) alongside TLS 1.3. It would be very nice if we can only deprecate RSA PKCS#1 1.5 at some point. regards, Nikos [0]. https://github.com/tlswg/tls13-spec/pull/1123 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Closing on PSS. PR#1114
On Tue, 2017-12-05 at 12:00 +0100, Nikos Mavrogiannopoulos wrote: > On Mon, 2017-12-04 at 17:24 -0800, Eric Rescorla wrote: > > Hi folks, > > > > I've put together a PR that attemps to address the PSS issue. > > > > See: > > https://github.com/tlswg/tls13-spec/pull/1114 As I guess, we cannot mandate RSA-PSS private keys and certificates for TLS1.3, I've followed up with a subsection on security considerations for re-using the RSA and RSA-PSS private keys. That includes recommendations to reduce the impact from cross-protocol attacks affecting these keys. https://github.com/tlswg/tls13-spec/pull/1123 regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Closing on PSS. PR#1114
On Mon, 2017-12-04 at 17:24 -0800, Eric Rescorla wrote: > Hi folks, > > I've put together a PR that attemps to address the PSS issue. > > See: > https://github.com/tlswg/tls13-spec/pull/1114 > > > Because there are platforms which don't have any support for PSS in > the cert validator, at all, it seems like we MUST be able to express > the following: > > 1. I accept PSS in CV, but nowhere in certificates, and the SPKI >MUST be of type rsaEncryption (because this is what Chrome >can do on some platforms). > > Going forward, we want to be able to express: > > 2. I accept PSS in CV *and* everywhere in the certificate chain >(otherwise PSS certificates are dead) > > 3. I accept EdDSA in CV but not for signing certificates >(note that this is subtly different from the PSS case because >you would need an EdDSA SPKI) > > 4. I accept EdDSA in CV and everywhere in the cert chain I do not see why specific platform considerations should lead such a major protocol change, at the cost of the platforms which can accomodate the requirements. I believe that such major moves for compatibility for specific platforms should be explicitly expressed in the WG charter. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR to clarify RSASSA-PSS requirements
On Wed, 2017-11-22 at 12:15 +, Peter Wu wrote: > Hi Nikos, > > On Wed, Nov 22, 2017 at 09:42:04AM +0100, Nikos Mavrogiannopoulos > wrote: > > On Wed, 2017-11-22 at 03:54 +, Peter Wu wrote: > > > Hi, > > > > > > At the moment there is still ambiguity in the requirements for > > > PSS > > > with > > > relation to certificates. Proposal to clarify this: > > > https://github.com/tlswg/tls13-spec/pull/1098 > > > > > > > > > This PR intends to clarify the requirements for PSS support. > > > > Hi, > > I commented on the PR, but to provide more context. I believe RSA- > > PSS > > keys without parameters MUST be supported under TLS1.3. The reason > > is > > that keys explicitly marked as RSA-PSS cannot be used for RSA > > PKCS#1 > > 1.5 encryption, and thus they provide a way for the server to know > > that > > it must protect that key against (cross-protocol) attacks which > > utilize > > RSA ciphersuites under TLS1.2. > > > > On why you don't want mixing keys for TLS1.3 and TLS1.2 RSA > > ciphersuites, see all the bleichenbacher attack reiterations over > > the > > years. > > > > So what about distinguishing the RSA-PSS keys with and without > > parameters: > > > > "an RSASSA-PSS public key (OID id-RSASSA-PSS) without parameters > > MUST > > be supported, while an RSASSA-PSS public key (OID id-RSASSA-PSS) > > with > > parameters MAY be supported`." > > In my understanding, the parameters are REQUIRED (cannot be NULL), > but > an "empty" DER encoding means that the default parameters are used > (SHA-1, MFG1 with SHA-1, salt length equal to SHA-1 output (20), > default > trailer) per https://tools.ietf.org/html/rfc8017#page-75 That's not what the DEFAULT keyword means in ASN.1. My understanding is that the default value applies when there is a sequence without that value present, not when the sequence is not there at all. Nevertheless, irrespective of that interpreation, for TLS1.3 an empty DER encoding means nothing of that as these parameters are negotiated over TLS (e.g, rsa_pss_sha256). See: https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.2.3 On whether empty parameters are allowed on RSA-PSS certificates, RFC4055 is clear on that: "CAs MAY require that the parameters be present in the publicKeyAlgorithms field for end-entity certificates." https://tools.ietf.org/html/rfc4055#section-3 regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR to clarify RSASSA-PSS requirements
On Wed, 2017-11-22 at 03:54 +, Peter Wu wrote: > Hi, > > At the moment there is still ambiguity in the requirements for PSS > with > relation to certificates. Proposal to clarify this: > https://github.com/tlswg/tls13-spec/pull/1098 > > > This PR intends to clarify the requirements for PSS support. Hi, I commented on the PR, but to provide more context. I believe RSA-PSS keys without parameters MUST be supported under TLS1.3. The reason is that keys explicitly marked as RSA-PSS cannot be used for RSA PKCS#1 1.5 encryption, and thus they provide a way for the server to know that it must protect that key against (cross-protocol) attacks which utilize RSA ciphersuites under TLS1.2. On why you don't want mixing keys for TLS1.3 and TLS1.2 RSA ciphersuites, see all the bleichenbacher attack reiterations over the years. So what about distinguishing the RSA-PSS keys with and without parameters: "an RSASSA-PSS public key (OID id-RSASSA-PSS) without parameters MUST be supported, while an RSASSA-PSS public key (OID id-RSASSA-PSS) with parameters MAY be supported`." regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#1091: Changes to provide middlebox robustness
On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote: > > > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd > wrote: > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar > > wrote: > > > FWIW: In my experience middleboxes don't ossify based on what the > > spec says, > > > they ossify based on what they see on the wire. So, if common > > > implementations send CCS in a particular way, that's what will > > get --- and, > > > I'll argue, what has gotten --- ossified. I also agree with David > > and Eric > > > that compatibility mode shouldn't be required because QUIC > > doesn't need it. > > > > What does compatibility mode mean here? > > It means: > > 1. Send the fake session_id > 2. Send a bunch of spurious CCS values. > > > > If we end up with having two > > slightly different versions of TLS 1.3, one that looks more like > > TLS > > 1.2 and the other that does not, that doesn't seem like a good > > thing > > to me. > > Well, the idea is that this is a purely local decision by one side. Which increases the cost of TLS1.3 implementation and testing by introducing different handshake state machines. Why not negotiate that CCS addition with an extension and have it defined outside the TLS 1.3 spec? I understand the concerns of the browser "community" on being 100% backwards compatible with middle boxes, but the TLS1.3 standard is more than just browsers. If 100% compatibility is required, there is a very simple solution, use TLS 1.2. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Preshared Keypairs for (D)TLS 1.2
On Thu, 2017-10-26 at 15:03 +, Tony Putman wrote: > Hi all, > > I've recently started working in the IoT space and wish to > standardize > our transport security by introducing the use of DTLS. It seems that > the > usual practice is to use PSK for mutual authentication, but I'm not > happy with this solution. A breach of server security allows not only > server impersonation, but also, due to the PSK symmetry, client > impersonation. If you worry about server impersonation in TLS1.2 there are the RSA-PSK ciphersuites which require the server to utilize its private key in RFC4279. If you worry about client impersonation there is TLS with SRP (RFC5054), which can also provide protection against server impersonation on the SRP-RSA mode. The latter is only defined over FF, i.e, there is no EC-based version of SRP defined for TLS. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3 ACKs
On Mon, 2017-10-23 at 18:14 -0700, Eric Rescorla wrote: > We now have DTLS 1.3 implemented in NSS, which went pretty cleanly. > > The one thing we ran into was the potential need to ACK in cases > where you > can't process *any* records (e.g., you receive what's actually EE, > but you > can't decrypt it). In this case, you want to send an empty ACK. > > See PR: > https://github.com/tlswg/dtls13-spec/pull/14 Would it make sense to spell out the goals (and maybe some motivation) for the DTLS 1.3 revision in the draft? The TLS WG charter contains the goals for the TLS 1.3 revision but changes in DTLS like the ACK although nice, seem to be unrelated to them. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Connection ID Draft
On Wed, 2017-10-18 at 06:43 +, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > Hi Nikos, > > On 13/10/2017, 07:21, "TLS on behalf of Nikos Mavrogiannopoulos" -boun...@ietf.org on behalf of n...@redhat.com> wrote: > > Another worrying feature is that the client can make the server > > send > > up to 255 verbatim bytes on the wire of his choice. Why was this > > feature added? Are there use cases related with it (intro doesn't > > mention any), or it was only thought as a make it as generic as > > possible approach? If it is the latter, I'd recommend to provide a > > simple approach that covers the described use cases. > > > > The same argument applies to the server being able to set such a > > long > > sequence of verbatim bytes to each of the client packets. > > I'd like to get a better understanding of your concern here. > Is it size? I had in mind scenarios of using these bytes to make the peer of talk another protocol with an unsuspecting party, or using the peer to attack a middle box which parses packets, e.g, by attempting buffer overflows to it. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Connection ID Draft
On Thu, 2017-10-12 at 16:13 -0700, Eric Rescorla wrote: > Hi folks, > > I have just posted a first cut at a connection ID draft. > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 I believe the major issue with that is the fact that the record packet format changes, but there is no way for a party in between to be able to determine the record packet format without keeping session state. Think not only of middle boxes, but of super-servers which may receive of a stray udp packet which they have to forward to the appropriate server [0]. With that change, they cannot figure whether the packet contains the CID or not in a deterministic way for a random CID. One can hack around that limitation by providing a CID which starts with 0x which is an illegal size currently for TLS or DTLS, but would have to worry with future extensions to the protocol which may increase the maximum size. Another worrying feature is that the client can make the server send up to 255 verbatim bytes on the wire of his choice. Why was this feature added? Are there use cases related with it (intro doesn't mention any), or it was only thought as a make it as generic as possible approach? If it is the latter, I'd recommend to provide a simple approach that covers the described use cases. The same argument applies to the server being able to set such a long sequence of verbatim bytes to each of the client packets. regards, Nikos [0]. That was exactly my use case for introducing the CID info, as in openconnect server, the super-server receives the stray UDP packets arriving after a NAT disassociates existing connections. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"
On Tue, 2017-09-12 at 14:41 +0100, Dr Stephen Henson wrote: > On 11/09/2017 19:42, Eric Rescorla wrote: > > Ugh. > > > > Generally, the idea with signature schemes is that they are > > supposed to reflect > > both the capabilities of your TLS stack and the capabilities of > > your PKI > > verifier [0]. So, yes, if you advertise this it is supposed to > > work. So, ideally > > we would just say that it's as Ilari says in his followup. > > > > It seems like there are really two choices: > > > > 1. Only advertise algorithm X if you support algorithm X in both > > places > > 2. Invent a new extension whose semantics are "if present, this > > tells you what > > the PKI validator accepts, otherwise look at signature schemes" > > > > I hate to be suggesting #2 at this stage in the process, but maybe > > it's right > > anyway... > > > > It's rather more than just certificate signatures. > > The problem here is that there is no way to indicate an > implementation supports > rsaEncryption keys but not RSASSA-PSS keys and the current draft > requires that > implementations support both AFAICS. > > RSASSA-PSS keys are pretty rare at the moment. There are some > complications > involved with supporting them not present with other key types: more > complex parameter sets and key restrictions for example. Right, that is indeed a significant complexity, and unfortunately the RSASSA-PSS parameters in certificates/keys are quite uniquely in PKIX. However, these are optional parameters, and one could support RSA-PSS keys without such parameters/restrictions relatively easily. Moreover, keys without paramters, are the keys which are typically expected to be used by TLS. That is, because a TLS server would typically sign with whatever algorithm the client supports and would very rarely be interested to utilize the security advantages of including the parameters (which, advantages, are quite unclear even to a crypto expert). Otherwise, a certificate restricted to SHA-384 and 48-bytes of salt, will not be able to serve a client which only supports RSASSA-PSS with SHA-256. As such, it would make sense for TLS 1.3 to recommend no parameters for such RSASSA-PSS certificates, to ease their deployment. > Implementors might feel > (despite what the draft says) that the added complexity is not > justified because no one will ever want to use RSASSA-PSS keys. If an implementation does not support RSASSA-PSS-only keys, it means it will (as a server) not be able to use separate keys for RSASSA-PSS and RSA PKCS#1 v1.5 operations, right? That's quite a fundamental limitation and if it exists in popular implementations it makes the TLS 1.3 move to RSASSA-PSS quite questionable. It may be better to support RSA PKCS#1 v1.5 in TLS1.3 alongside RSASSA-PSS (for the implementations that chose to opt-in), rather than forcing a move to RSASSA-PSS without providing any of the benefits of using it. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"
On Mon, 2017-09-11 at 11:42 -0700, Eric Rescorla wrote: > Ugh. > > Generally, the idea with signature schemes is that they are supposed > to reflect both the capabilities of your TLS stack and the > capabilities of your PKI verifier [0]. So, yes, if you advertise this > it is supposed to work. So, ideally we would just say that it's as > Ilari says in his followup. > > It seems like there are really two choices: > > 1. Only advertise algorithm X if you support algorithm X in both > places > 2. Invent a new extension whose semantics are "if present, this tells > you what the PKI validator accepts, otherwise look at signature > schemes" > > I hate to be suggesting #2 at this stage in the process, but maybe > it's right anyway... > > -Ekr > > [0] I recognize that there are people who think that TLS shouldn't > say anything about the PKI verifier, > but I don't think that this is viable, for exactly the reason shown > here: it's possibly to have an algorithm which is widely supported in > TLS stacks but not in PKI verifiers. In practice, I find it perfectly reasonable for stacks which do not support that algorithm in both PKI and TLS not to advertise it. The option (1) brings simplicity to a rather complex protocol, while (2) bloats the protocol for the benefit of helping not up-to-date stacks claim TLS 1.3 compliance. In theory, the only reason for having RSA-PSS is its security proof. Mixing RSA (certificates) and RSA-PSS (handshake) in a protocol may hardly bring any benefit; it looks like it will make a convoluted protocol without particular goal or focus. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size
On Fri, 2017-08-11 at 14:45 -0400, Daniel Kahn Gillmor wrote: > On Fri 2017-08-11 18:43:15 +0200, Nikos Mavrogiannopoulos wrote: > > I don't argue with this but this is not the approach TLS 1.3 took. > > It > > provides a generic padding mechanism to be used across application > > protocols. > > The design approach that TLS 1.3 took was to provide a mechanism for > padding at the TLS layer, not to prescribe padding at the application > layer. You actually probably need both to defend against traffic > analysis in the big picture. > > Thoughtful, well-designed application-layer padding is likely to be > better than generic TLS-layer padding. But not all applications can > actually accomodate padding (and it's not clear that folks have done > the > thoughtful work even on those applications which *can* accomodate > padding). > > TLS offers a generic mechanism to support the cases where the > application can't do padding, or where the implementer has no control > over (or insight into) the application itself. It'll probably leak > in > the way you describe, but it'll probably also be better than > cleartext. > > Furthermore, there are TLS messages that are not application data at > all -- so those parts *have* to be padded at the TLS layer, as the > application cannot directly affect their size. > > A robust and safe padding approach needs to take into account all > layers > of the stack at once and coordinate between them. Without the > padding > mechanism in TLS, it wouldn't be possible to coordinate across the > whole stack. Typically protocol design which is build on top of other protocols assumes that they operate as reasonably. I doubt a TLS implementor who knows about this timing leak will be the one designing the application protocol on top, so my bet is that we are going to see application protocols defined which take advantage of that padding and believing they offer a plaintext length protection. That's why, I'd urge to underline this timing leak in the document rather than hiding it in generic timing leak considerations text. We already have experience with that. TLS 1.1 documented a similar leak prominently: "Implementation Note: Canvel et al. [CBCTIME] have demonstrated a ..." Note however that documenting the problem itself didn't help in that case, all implementations were vulnerably to the later lucky13 attack. The best IMHO is to document the way to address the timing leak. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size
On Fri, Aug 11, 2017 at 5:57 PM, Eric Rescorla wrote: > > On Fri, Aug 11, 2017 at 7:11 AM, Nikos Mavrogiannopoulos > wrote: > >> Imagine the following scenario, where the server and client have this >> repeated communication N times per day: >> >> client server >> --X--> >> <--Y-- >> >> >> the client puts in X a message A of 1 byte or B of 1024 bytes, and pads >> it to the maximum size of TLS record. The server replies with the >> message "ok" (same every time), padded to the maximum size just after >> it reads X. >> >> However, TLS 1.3 detects the message size by iterating through all the >> padding bytes, and thus there is a timing leak observed by the time >> difference between receiving X and sending Y. Thus as an adversary I >> could take enough measurements and be able to distinguish between X >> having the value A or B. >> >> While I'd expect these iterations to be unmeasurable in desktop or >> server hardware, I am not sure about the situation in low-end IoT >> hardware. Is the design choice for having the padding removal depending >> on padding length intentional? > > > Yes, we're aware of this, and it's an intentional design choice. The > reasoning > was that once you have the padding removed, you'll need to operate on/copy > the unpadded content somewhere, and that's timing dependent anyway. > That is certainly an incorrect assumption. gnutls for example provides a zero-copy API, and I guess it is not the only implementation to have that. > > >> There is mentioning of possible timing channels in: >> https://tools.ietf.org/html/draft-ietf-tls-tls13-21#appendix-E.3 >> However I don't quite understand how is this section intended to be >> read. The sentence for example: "Because the padding is encrypted >> alongside the actual content, an attacker cannot directly determine the >> length of the padding, but may be able to measure it indirectly by the >> use of timing channels exposed during record processing", what is its >> intention? Is it to acknowledge the above timing leak? >> > > Yes. > I am not sure if that text is sufficient to cover that issue. It seems as if the cbc timing attack is re-introduced here and pushing the fix to implementers. It may be better no to provide padding functionality with this "feature", as unfortunately it will be used by applications. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size
On Fri, Aug 11, 2017 at 5:17 PM, Short, Todd wrote: > The application can solve this by having its own padding. If it’s going to > force all messages to be padded out to 1024 bytes by TLS, why not just make > that part of the application protocol? Its not as though it’s trying to > save bytes here. > I don't argue with this but this is not the approach TLS 1.3 took. It provides a generic padding mechanism to be used across application protocols. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size
Imagine the following scenario, where the server and client have this repeated communication N times per day: client server --X--> <--Y-- the client puts in X a message A of 1 byte or B of 1024 bytes, and pads it to the maximum size of TLS record. The server replies with the message "ok" (same every time), padded to the maximum size just after it reads X. However, TLS 1.3 detects the message size by iterating through all the padding bytes, and thus there is a timing leak observed by the time difference between receiving X and sending Y. Thus as an adversary I could take enough measurements and be able to distinguish between X having the value A or B. While I'd expect these iterations to be unmeasurable in desktop or server hardware, I am not sure about the situation in low-end IoT hardware. Is the design choice for having the padding removal depending on padding length intentional? There is mentioning of possible timing channels in: https://tools.ietf.org/html/draft-ietf-tls-tls13-21#appendix-E.3 However I don't quite understand how is this section intended to be read. The sentence for example: "Because the padding is encrypted alongside the actual content, an attacker cannot directly determine the length of the padding, but may be able to measure it indirectly by the use of timing channels exposed during record processing", what is its intention? Is it to acknowledge the above timing leak? Shouldn't instead be guidance in section 'Implementation Pitfalls' on how to remove padding in a way that there are no timing leaks? (the timing leak here is not in crypto algorithms, but TLS itself). Ideally TLS 1.3 itself shouldn't use data-size depending calculations itself such as the one described here. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] chairs - please shutdown wiretapping discussion...
On Mon, 2017-07-10 at 13:54 +, Polk, Tim (Fed) wrote: > First, I do not see this as a “wiretapping discussion” based on my > reading of 2804, although others may disagree. > > Second, I believe that this discussion should go forward based on > several points: > this proposal does not involve any changes to the bits on the wire > specified in the TLS 1.3 document > this proposal offers significantly better security properties than > current practice (central distribution of static RSA keys) > alternative solutions with significantly worse security properties > are also feasible under TLS 1.3, and I would like to avoid them! > > We should be in the business of developing pragmatic, interoperable > solutions with appropriate security properties. Balancing > cryptographic security with other security requirements to achieve > such solutions should be an acceptable path, and pursuing this work > in the TLS working group gives the IETF the best opportunity to > influence these solutions. Certainly, but that doesn't need to happen on this working group, nor protocols which implement similar solutions need to be called TLS. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] signature algorithm ID re-use
On Wed, Jul 5, 2017 at 12:50 AM, Martin Thomson wrote: > On 4 July 2017 at 07:43, Nikos Mavrogiannopoulos wrote: > > So my question is why not go for the simpler approach and create new > > identifiers for the new signature algorithms? (similarly to RSA-PSS). > > Is there an advantage of re-using the ECDSA signature algorithm > > identifiers to mean something different in TLS 1.3? Was there some > > discussion on the topic on the list? > > > This was fairly extensively litigated. I remember Hannes asking > exactly the same question, but I forget which in-person meeting it > was. It might have been IETF 97. > > Unfortunately, any search I do on this subject turns up the hundreds > of emails on using signature algorithms for selecting certificates. > > What I've found is that this isn't that difficult to implement > correctly, even across versions. As David Benjamin suggested in > earlier emails, you can change to using a 16-bit codepoint in your > code. Then you add a curve-matching restriction if the selected > version is TLS 1.3 (or greater). > Well, it depends on the definition of correctly :) You can certainly have interoperation following something similar to what you describe, however the question is what about semantics. How do you translate that to the user? If one is careful with semantics and would like to let the user specify a policy of allowed operations/signature algorithms, he would have to specify two different signature algorithms, one for ecdsa with any curve, and another for the restricted to secp256r1, and then make sure that what is sent over the wire will be interpreted according to the policy by a TLS 1.2 or a TLS 1.3 server (which I find it quite impossible for any policy which requires anything else than a single curve and signature algorithm). That's why my question is on what is the advantage of the code point re-use, because I see only disadvantages. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] signature algorithm ID re-use
Hi, The latest TLS 1.3 draft re-uses the sha256(4), sha384(5), sha512(6) with ecdsa(3) signature algorithms IDs for the following signature algorithms: /* ECDSA algorithms */ ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), ecdsa_secp521r1_sha512(0x0603), These are similar but have different semantics; as indicated by their name they can be used with a single curve. That makes the handshake conversation something like: Client: Use ecdsa_secp256r1_sha256 under TLS 1.3 or ecdsa with whichever curve and sha256 if under TLS 1.2. That apart from being confusing, means that a client which is willing to fallback to TLS 1.2 cannot restrict its options to ecdsa_secp256r1_sha256 (i.e., require the secp256r1 curve for signatures). One could work-around it, by utilizing the elliptic curves extension, but that has also different semantics under TLS 1.3. So my question is why not go for the simpler approach and create new identifiers for the new signature algorithms? (similarly to RSA-PSS). Is there an advantage of re-using the ECDSA signature algorithm identifiers to mean something different in TLS 1.3? Was there some discussion on the topic on the list? [0]. https://github.com/tlswg/tls13-spec/issues/1035 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] comments on draft-ietf-tls-tls13-19
On Mon, 2017-04-24 at 09:26 -0400, Ryan Sleevi wrote: > > > On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos .com> wrote: > > That's intentional. > > And misguided. It violates the layering. That's a respectable opinion. I disagree. > > The reason they > > cannot be expected to do that, is that it is not by way obvious > > what to > > do. Ilari's implentation closes the connection, mine sets a limit > > of 15 > > days, and I guess each and every other one behaves differently. It > > is > > the role of the standards to clarify uncertainties for implementers > > or > > forbid such options (I'd equally be happy if we have a text that > > forbids an empty nextUpdate field in OCSP responses to be used in > > the > > context of TLS 1.3 ocsp stapling). > > Can you point to where the spec supports your behaviours? That is, > where it's a valid reading of the spec to close the connection or to > set a limit of 15 days. > > The point is that it's not a valid reading of the spec. It is, > instead, an application profile. And that's great. I don't think > anyone would realistically be arguing that applications or other > specifications cannot profile the spec to their needs. While I remain > unconvinced that TLS is the right thing, what you're describing here > is simply a decision you've made for your community. That doesn't > mean that because you and Ilari have made different decisions, that > should be imposed on the spec. > > > > Given that stapling "issues" exist even without stapling, it > > does > > > seem an unnecessary reach to include within the spec. > > > > There is a usability and interoperability issue there. > > Not within the spec. Within the profile you've done for your > community. So you point is that as long as you don't use OCSP responses there is no interoperability issue. That's very interesting point. More interestingly you delegate that definition to an application profile. Could you refer to such application profiles for TLS which define how OCSP responses are to be used? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] comments on draft-ietf-tls-tls13-19
On Sun, 2017-04-23 at 12:01 -0400, Ryan Sleevi wrote: > > > > As for what the TLS library I have written does if OCSP staple > > lacks > > NextUpdate, it outright causes handshake failure and fatal alert. > > So far, the preference on our end has been for a TLS library that > doesn't have to have deeply-ingrained knowledge of the PKI, including > OCSP, and instead treat these as separate layers. This PR > necessitates that awareness by force of spec, That's intentional. Not every application is firefox or chrome and thus application writers cannot be expected to set sane defaults for OCSP validity time _when the nextUpdate field is missing_. The reason they cannot be expected to do that, is that it is not by way obvious what to do. Ilari's implentation closes the connection, mine sets a limit of 15 days, and I guess each and every other one behaves differently. It is the role of the standards to clarify uncertainties for implementers or forbid such options (I'd equally be happy if we have a text that forbids an empty nextUpdate field in OCSP responses to be used in the context of TLS 1.3 ocsp stapling). > Given that stapling "issues" exist even without stapling, it does > seem an unnecessary reach to include within the spec. There is a usability and interoperability issue there. Given that there is no common interpretation of what the missing nextUpdate field means in terms of validity, there some equally valid interpretations: 1. the response is invalid for use in TLS 1.3 2. the response is valid for a limited amount of time 1, 7, 8, 9, 15 days 3. the response is valid for an unlimited amount of time (which raises the question of why staple at all in that case?) Without a clarification in the spec, we are going to see implementations that fail when encountered with such response, implementations that work fine, and implementations that claim the response is too old. That would most likely result to ocsp stapling becoming the thing to disable for things to work. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] comments on draft-ietf-tls-tls13-19
On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > 4.1.1. HelloRetryRequest how many times can it be re-sent by the > > server? I assume only a single one, but it maybe good to make it > > explicit. > > This is forbidden in S 4.1.4. > https://tlswg.github.io/tls13-spec/#hello-retry-request > > If a client receives a second HelloRetryRequest in the same > connection (i.e., where the ClientHello was itself in response to > a > HelloRetryRequest), it MUST abort the handshake with an > “unexpected_message” alert. > > Does this seem sufficient? I must have missed it. Yes, it seems fine. > > 4.4.2.1. OCSP Status and SCT Extensions > > This is a very nice addition to TLS 1.3. Something that I miss as > an > > implementer is guidelines on how to determine the (time) validity > of an > > OCSP stapled response. Here my point is that OCSP responses have > > several fields optional (e.g., nextUpdate), which make a validation > to > > be hand-wavy. It would be nice to have a profile of OCSP responses > that > > would be recommended for use in TLS, as well or a recommendation of > > what constitutes a "fresh" response for use in TLS. > > Do you have any thoughts on what text we should insert here? I admit > to being not that familiar with the practical matters of OCSP > stapling. My issue with OCSP when used under TLS was how to determine the validity of the response when the nextUpdate field is missing. I've added some text for that introducing an (arbitrary) upper limit at: https://github.com/tlswg/tls13-spec/pull/974 > > 5.1. I miss a maximum number of alerts received per session, or > some > > other alert limiting mechanism (having CVE-2016-8610 in mind). > > All alerts now result in connection termination, so the limit > seems to implicitly be 1. Nice. > > > > 7.5. There is no definition of early_exporter_secret, and it is > unclear > > why it is even mentioned. In short how is this supposed to be used, > and > > why should implementations consider adding an interface to it? > > It is defined in: > https://tlswg.github.io/tls13-spec/#key-schedule > > I added some text to explain why you would want it. Thanks. There is a typo on that description "is define for use" -> "is defined for use". regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] comments on draft-ietf-tls-tls13-19
On Wed, 2017-03-29 at 16:28 +0200, Nikos Mavrogiannopoulos wrote: > A more general note on the section/document, is that although the > PKIX > identity (certificate) is protected from passive adversaries, the PSK > identity is not. This is a discrepancy in terms of protecting the > user's identity between PSK and certificate authentication (that > should > warrant . ... an entry in the security considerations. > 4.2. rfc6961 is standard's track but TLS 1.3 only uses the RFC6066 > status request. Why not require RFC6961? Please ignore that. I forgot to delete in my draft. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] comments on draft-ietf-tls-tls13-19
Hi,
In this mail I summarize my comments for draft-ietf-tls-tls13-19
(which I have read but not implemented). They include both editorial
comments and content comments. Overall this is a very good document,
congratulations to everyone involved.
On the following text, I use the format Section: Comment.
1.2. Major Differences from TLS 1.2
It is very hard to make use of this section as is. It is organized on
per-draft, while it would be expected to have the changes of the
document since TLS 1.2. It contains phrases like "Remove spurious
requirement to implement "pre_shared_key"." At its current state it is
not useful to someone familiar with TLS 1.2.
2. Figure 1 ascii art is a bit awkward (IMHO). "Key Exch" looks like
bad shortening. Symbols '^' and 'v' were confusing on the first read.
A suggestion could be to avoid ^v, and define shortened terminology
upfront and use it on the figures.
One the content, Figure 1 contents are too many to swallow at an
overview. A suggestion would be to split into two diagrams (preshared
keys and not).
A more general note on the section/document, is that although the PKIX
identity (certificate) is protected from passive adversaries, the PSK
identity is not. This is a discrepancy in terms of protecting the
user's identity between PSK and certificate authentication (that should
warrant .
4.1.1. HelloRetryRequest how many times can it be re-sent by the
server? I assume only a single one, but it maybe good to make it
explicit.
4.1.2. It is not defined what a server should do if encountered with a
ProtocolVersion of TLS 1.3.
4.2. rfc6961 is standard's track but TLS 1.3 only uses the RFC6066
status request. Why not require RFC6961?
4.2. the exception for including cookie in HelloRetryRequest seems like
something that could cause issues in future revisions. Any future
revision of the protocol would not be able to add such exceptions
(since they will be rejected by existing clients), and the fact that
the cookie is there, it indicates that such an exception may be useful.
A suggestion to address that would be to allow the HelloRetryRequest
contain any extension or grant an exception to a specific extension
number range.
4.2.5.2. The parameters are informally defined.
I'd suggest to follow rfc4492bis and use its text as in:
https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-16#section-5.4.1
4.2.7. There is no guidance on the use of max_early_data_size.
I'd find it natural to have a recommended minimum value for application
protocols layered on TLS to take into account. E.g., text like servers
supporting early_data SHOULD allow at least 1024 bytes of data
(arbitrary number). Is the 32-bit upper limit intentional?
4.2.8. This section changes the semantics for pre-shared keys as used
in any other protocol (including TLS 1.2). With the new text it
implies, pre-shared keys must be combined with a hash algorithm. Thus
existing PSK deployments which share keys and would like to upgrade to
TLS 1.3 cannot do transparently. They would have to fix to a specific
hash algorithm for their existing PSKs, and make sure they provide that
information to all the underlying software (which may be different on
the server and client side). I could find no implementation guideline
on what to do in the case of pre-existing PSKs in that text.
My recommendation would be to switch the sentence "For externally
established PSKs, the Hash algorithm MUST be set when the PSK is
established" to "For externally established PSKs, the Hash algorithm
MUST be set when the PSK is established, or default to SHA-256". That
way implementations can cope transparently with an upgrade to TLS 1.3
for already present PSK keys without requiring an additional RFC
describing that.
4.2.8. The overlap of the namespace for usernames to be used in PSK
authentication, and the namespace for "resumption" does not give a good
feeling.
4.2.8. Related to the above, it is unclear what obfuscated_ticket_age
should contain when using PSK authentication (but not resumption).
4.2.8.1. It is not defined what the binder should contain when using
PSK authentication (but not resumption).
4.2.8.1. If a single binder corresponds to a single identity, the
parsing and mapping of binders in the PreSharedKeyExtension seems
unnecessarily complicated. A suggestion is to move the binder inside
each identity structure:
struct {
opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age;
opaque PskBinderEntry<32..255>;
} PskIdentity;
4.2.8.3. I believe that section can benefit from some improvements.
>From a first read it is not clear what this section wants to protect
from. It provides some checks, but it is unclear to me what these
protect from.
Some more concrete comments on the same section:
It mentions "see if the value used by the client matches its
expectations". A question that arises, is what is the recommended
expectation for a server? Given the text in 4.2.8 that should be a
week, but
Re: [TLS] RFC 6066 - Max fragment length negotiation
On Tue, 2017-03-21 at 14:15 +0100, Thomas Pornin wrote: > On Fri, Mar 17, 2017 at 05:24:09PM +1100, Martin Thomson wrote: > > I'd even go so far as to specify it: > > > > https://martinthomson.github.io/tls-record-limit/ > > > > I'll submit an I-D once the blackout ends if people are interested > > in this. > > I like this proposal. One comment, though: I think the wording in > section 4 should mandate that the value sent MUST NOT exceed the > maximum > record size -- i.e. if an implementation supports records up to 16384 > bytes, then it should put 16384 here, not a bigger value suc as > 65535. > > Rationale: last time this was discussed on this list, some people > expressed the wish to ultimately support records with more than 16384 > bytes of plaintext. If such an extension ever comes to fruition (it > is > certainly easy enough to do with CBC and GCM cipher suites), then > sending a record_size_limit with a limit of, say, 6 bytes, would > serve as indication that the implementation indeed supports such > larger > records. This holds only as long as no implementation sends a value > larger than 16384 if it does not really accept records of more than > 16384 bytes. > > Therefore, I propose to replace this paragraph: > > An endpoint that has no limit on the size of data they receive > can > set this value to any value equal to or greater than the maximum > possible record size, such as 65535. A larger value does not > allow > the endpoint to send larger records than the protocol permits. An > endpoint that receives a value larger than the maximum defined in > the protocol MUST NOT exceed protocol-defined limits. For TLS 1.3 > and earlier, this limit is 2^14 octets. > > with the following: > > An endpoint that supports all sizes that comply with the > protocol-defined limits MUST send exactly that limit as value for > maximum record size (or a lower value). For TLS 1.3 and earlier, > that limit is 2^14 octets. Higher values are currently reserved > for > future versions of the protocol that may allow larger records; an > endpoint MUST NOT send a value higher than 2^14 unless explicitly > allowed by such a future version and supported by the endpoint. > > When an endpoint receives a maximum record size limit larger than > the protocol-defined limit, that end point MUST NOT send records > larger than the protocol-defined limit, unless explicitly allowed > by > a future TLS version. I support this proposal. It actually prevents re-introducing a limitation which can hamper a future modification of the scope of this extension. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "Spec Compliance" and the older TLS protocols
On Fri, 2017-03-03 at 15:32 -0800, Bradford Wetmore wrote: > An interpretation question for our older RFCs, in particular TLSv1 > [RFC2246] and TLSv1.1 [RFC4346] in the context of recent > developments > [SWEET32]. > > In particular, likely for minimal interoperability reasons, specific > 3DES-based ciphersuites must be implemented in TLS: > > TLS 1.0 > > In the absence of an application profile standard specifying > otherwise, a TLS compliant application MUST implement the cipher > suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. > > TLS 1.1 > > In the absence of an application profile standard specifying > otherwise, a TLS compliant application MUST implement the cipher > suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. I do not think the TLS 1.0 MUST requirement for a mandatory ciphersuite was ever implemented at the time TLS 1.0 was the latest protocol. None of the browsers of the time supported TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. TLS 1.1 was modified to reflect the actual situation as you see above. > So, strictly speaking from a RFC point of view (not practical or > security POV, those are different questions), what do these "MUST > implement" statements mean in order for an implementation to still > be > considered "spec-compliant" in the post-SWEET32 era. 1-2 above? 1- > 3? > [RFC2119] isn't clear on whether 3 would be ok. Spec compliance at the time of TLS 1.0 and TLS 1.1 was interoperation with the available browsers and servers. The spec itself didn't result to guaranteed interoperability. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PSS and TLS 1.3
- Original Message - > On Mon, Feb 06, 2017 at 01:12:05AM +0100, Nikos Mavrogiannopoulos wrote: > > > > The issue is that we cannot tell for sure. Any proof of security > > assumes that the keys are restricted to a single scheme. So I think we > > got into a trap where we intended to increase security, while in fact > > reduced the protocol's security, by ending-up adding RSA-PSS in a way > > that can share keys with PKCS#1 1.5. I think that we should treat RSA- > > PSS as the mean to increase security rather than the end-goal. > > Looking at the signature constructions, I would say it is _extremely_ > unlinkely that cross-protocol attacks are possible. Isn't the whole purpose of moving to formally proved schemes, the fact that there is a proof of security? This support by TLS 1.3 invalidates this proof, thus making any reason to have RSASSA-PSS moot, (unless of course we have a proof that RSASSA-PSS when combined with RSA PKCS#1 1.5 is secure). regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PSS and TLS 1.3
On Mon, 2017-01-23 at 12:52 +0200, Ilari Liusvaara wrote: > On Mon, Jan 23, 2017 at 09:05:28AM +0100, Nikos Mavrogiannopoulos > wrote: > > On Fri, 2017-01-20 at 17:43 +, Dr Stephen Henson wrote: > > > > > Additionally PSS signatures (see RFC4055) can be used with RSA > > > keys > > > (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). > > > Does > > > the RSASSA-PSS mean that both types must be accepted? > > > > That's a quite interesting finding. Although that protocol behavior > > seems to ease transition to RSASSA-PSS, it also paves the field for > > new > > cross protocol attacks. A server which can sign with either of > > RSASSA- > > PSS and RSA-PKCS1 and the same key is certainly less secure than a > > server which can sign with either of them. The only way to enforce > > that > > a key is restricted is by requiring the id-RSASSA-PSS OID for > > RSASSA- > > PSS. > > Unfortunately, dedicated RSA-PSS keys are pretty much undeployable, > and > requirement to use those would be de facto the same as removing RSA > server signatures entierely from TLS 1.3[1]. > > I don't know any CA that would certify RSA-PSS keys. And adding new > key > types is a slow process. Heck, Certifying ECDSA keys are poorly > supported among CAs[2]. > > And looking at RSA-PKCS1 and RSA-PSS, it doesn't seem likely that > there > exists a EM that is both valid in RSA-PKCS1 and RSA-PSS for any > messages, unless keysizes are too small, hashes are too large or > salts are too large. The issue is that we cannot tell for sure. Any proof of security assumes that the keys are restricted to a single scheme. So I think we got into a trap where we intended to increase security, while in fact reduced the protocol's security, by ending-up adding RSA-PSS in a way that can share keys with PKCS#1 1.5. I think that we should treat RSA- PSS as the mean to increase security rather than the end-goal. Even if the approach of separating keys would mean that RSA-PSS will not be deployed immediately, it will allow implementors to provide well-behaved clients that will refuse to mix marked as RSA-PSS keys with the legacy ones. On the current protocol description it is impossible for an implementor to do that. The reason is that if one does that, his software will not be functional, will fail to connect to several web servers, and thus will have to compromise (functionality always wins over security). > [2] Some commercial CAs (don't have list) and Let's Encrypt (signed > with RSA[3] and even then most ACME software can't handle those).. TLS 1.3 requiring a different key type, will provide an incentive for them to update. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PSS and TLS 1.3
On Fri, 2017-01-20 at 17:43 +, Dr Stephen Henson wrote: > Additionally PSS signatures (see RFC4055) can be used with RSA keys > (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). Does > the RSASSA-PSS mean that both types must be accepted? That's a quite interesting finding. Although that protocol behavior seems to ease transition to RSASSA-PSS, it also paves the field for new cross protocol attacks. A server which can sign with either of RSASSA- PSS and RSA-PKCS1 and the same key is certainly less secure than a server which can sign with either of them. The only way to enforce that a key is restricted is by requiring the id-RSASSA-PSS OID for RSASSA- PSS. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC7919 (4908)
On Sun, 2017-01-15 at 16:51 -0800, RFC Errata System wrote: > Original Text > - > If a compatible TLS server receives a Supported Groups extension > from > a client that includes any FFDHE group (i.e., any codepoint > between > 256 and 511, inclusive, even if unknown to the server), and if > none > of the client-proposed FFDHE groups are known and acceptable to > the > server, then the server MUST NOT select an FFDHE cipher suite. In > this case, the server SHOULD select an acceptable non-FFDHE cipher > suite from the client's offered list. If the extension is present > with FFDHE groups, none of the client's offered groups are > acceptable > by the server, and none of the client's proposed non-FFDHE cipher > suites are acceptable to the server, the server MUST end the > connection with a fatal TLS alert of type > insufficient_security(71). I understand there will be servers which cannot follow the alert recommendations on an RFC, but in that case why not replace the alert types recommendation with a RECOMMENDED or SHOULD? It is good practice for an RFC to specify the alerts to be send rather than leaving it up to the implementer to figure out. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3
On Tue, 2016-11-29 at 13:56 +0100, Hubert Kario wrote: > > Given that certificates usually take up most of the bytes exchanged > > during a > > full handshake it seems this could be useful, but I don't know if > > in > > practice the benefits are worth the added complexity. Thoughts? > > Decompressing completely untrusted and unverified data directly in > the > security library? > No, I don't think we need more complex code in TLS implementations. Well, PKIX/X.509 parsing seems to be order of magnitude more complex than compression :) regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3
On Sun, 2016-11-27 at 15:13 +, Alessandro Ghedini wrote: > On Sat, Nov 26, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote: > > I am currently trying to figure out how much of QUIC certificate > > compression can be adapted to work with TLS. I will submit a draft > > as soon > > as I have a working prototype. > > FWIW I too have started working on a prototype for gzip compressing > certificates > based on BoringSSL: > https://github.com/ghedo/boringssl/tree/cert_compress > > It's not complete yet and I only implemented compression so far based > on what > Chromium does with QUIC. I also haven't really tested it yet (but at > least it > builds AFAICT :) ). I guess one could use the certificate type negotiation mechanism from RFC7250 to negotiate a compressed certificate, instead of a normal one. That would require registering an ID at: http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml > I'd like to do some tests as well to measure the benefits of this > (e.g. > download certificates from CT logs and see how effective the > compression is). > > I also started working on a draft for gzip compression of > certificates at: > https://github.com/ghedo/tls-certificate-compression Have you considered lz4 instead of zlib? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] record layer limits of TLS1.3
Maybe a solution would be a better maximum fragment length extension which allows the size can be negotiated in a more fine-grained way, as pointed in: https://www.ietf.org/mail-archive/web/tls/current/msg12472.html I also found these requests asking for larger packet sizes. https://www.ietf.org/mail-archive/web/tls/current/msg13569.html https://mailarchive.ietf.org/arch/msg/tls/K_6Ug4GtAxbrQJy2CFFFoxxtJ60 On Wed, 2016-11-23 at 00:46 -0800, Judson Wilson wrote: > I worry about the buffer sizes required on embedded devices. > Hopefully the other endpoint would be programmed to limit record > sizes, but is that something we want to rely on? This could be a > parameter agreed upon during the handshake, but that seems bad. > > > On Wed, Nov 23, 2016 at 12:41 AM, Nikos Mavrogiannopoulos t.com> wrote: > > On Wed, 2016-11-23 at 00:39 -0800, Judson Wilson wrote: > > > Can you send multiple records in one data transfer to achieve > > > whatever gains are desired? > > > > The packetization cost still remains even if you do that. However, > > the > > question is how does the 2^14 limit comes from, and why TLS 1.3 > > should > > keep it? > > > > regards, > > Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] record layer limits of TLS1.3
On Wed, 2016-11-23 at 00:39 -0800, Judson Wilson wrote: > Can you send multiple records in one data transfer to achieve > whatever gains are desired? The packetization cost still remains even if you do that. However, the question is how does the 2^14 limit comes from, and why TLS 1.3 should keep it? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] record layer limits of TLS1.3
On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: > Hi, Nikos > > On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos > wrote: > > > > > Hi, > > Up to the current draft of TLS1.3 the record layer is restricted > > to > > sending 2^14 or less. Is the 2^14 number something we want to > > preserve? > > 16kb used to be a lot, but today if one wants to do fast data > > transfers > > most likely he would prefer to use larger blocks. Given that the > > length > > field allows for sizes up to 2^16, shouldn't the draft allow for > > 2^16- > > 1024 as maximum? > > I am not opposed to this, but looking at real browsers and servers, > we see that they tend to set the size of records to fit IP packets. IP packets can carry up to 64kb of data. I believe you may be referring to ethernet MTU sizes. That to my understanding is a way to reduce latency in contrast to cpu costs. An increase to packet size targets bandwidth rather than latency (speed). > The gains from increasing the size of records from the ~1460 bytes > that fit in a packet to nearly 64KB are not all that great, and the > gains from increasing records from 16 KB to 64KB are almost > negligible. At that size the block encryption dominates the CPU time. Do you have measurements to support that? I'm quite surprized by such a general statement because packetization itself is a non-negligible cost especially when encryption is fast (i.e., in most modern CPUs with dedicated instructions). regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] record layer limits of TLS1.3
Hi, Up to the current draft of TLS1.3 the record layer is restricted to sending 2^14 or less. Is the 2^14 number something we want to preserve? 16kb used to be a lot, but today if one wants to do fast data transfers most likely he would prefer to use larger blocks. Given that the length field allows for sizes up to 2^16, shouldn't the draft allow for 2^16- 1024 as maximum? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] extending the un-authenticated DTLS header
On Tue, 2016-11-15 at 18:20 +0900, Martin Thomson wrote: > On 15 November 2016 at 18:11, Nikos Mavrogiannopoulos m> wrote: > > > > > > > > I'm not seeing quite enough information here to implement > > > this. How > > > does a server know which of the many HOTP keys it has are in use? > > > Surely you can't use the same HOTP key with every client. > > > > Not sure I understand the question, but I'd suggest to read the > > text on > > generating the hotp keys. > > > OK, I re-read it. It wasn't particularly clear from the overview. > But you generate the HOTP based on an exporter. That means that the > server has no control over the contents of the CID, direct or > otherwise. This means that you can guarantee privacy, but it forces > the server to do an exhaustive search of all of its active > connections > (that is, O(N)) when it gets a 5-tuple mismatch. > > There are probably designs that don't have this property. For > instance, the server could propose an identifier or set of > identifiers. That means that a bad server could willfully break the > privacy property, but it also means that it doesn't have the scaling > issues. I think Thomas reply addresses that, or we must have misunderstood what you mean above. I think however that we are getting outside the scope of the initial discussion. Do you have a proposal which changes the TLSrecord header? If yes would you be interested in discussing ways to combine that, or ways to make the header extendable? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] extending the un-authenticated DTLS header
On Tue, 2016-11-15 at 18:10 +0900, Martin Thomson wrote: > On 15 November 2016 at 17:34, Fossati, Thomas (Nokia - GB) > wrote: > > > > The draft proposes two ways to allocate the identifier (see 3rd > > para of > > https://thomas-fossati.github.io/draft-tls-cid/#rfc.section.1): > > 1. Server decides unilaterally a value that is fixed for the > > duration of > > the session (SecAssocType.fixed); > > 2. Server and Client agree on a sequence of values generated using > > HOTP > > [RFC 4226] seeded by the session shared secret (SecAssocType.hotp); > > Client > > shifts to the next value when needed (e.g. on transport handover). > > > > > > At first this might not look particularly elegant, but there are > > good > > reasons for having both methods. > > I'm not seeing quite enough information here to implement this. How > does a server know which of the many HOTP keys it has are in use? > Surely you can't use the same HOTP key with every client. Not sure I understand the question, but I'd suggest to read the text on generating the hotp keys. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] extending the un-authenticated DTLS header
On Tue, 2016-11-15 at 09:10 +0900, Martin Thomson wrote: > On 14 November 2016 at 21:58, Nikos Mavrogiannopoulos m> wrote: > > > > For draft‐mavrogiannopoulos‐dtls‐cid‐00 and we needed to extend > > the > > DTLS un-authenticated part of the DTLS record header with an > > additional > > field. That works well if this is the only draft ever extending the > > DTLS record header. If not, modification order would be undefined. > > Where is this draft? The published version: https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-cid-00 The latest: https://github.com/thomas-fossati/draft-tls-cid/blob/master/draft-mavrogiannopoulos-tls-cid.md regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] extending the un-authenticated DTLS header
On Tue, 2016-11-15 at 01:10 +, Stephen Farrell wrote: > > Would it make sense to introduce an extension header for DTLS 1.3 > > in > > the lines of the IPv6 extension headers? That would allow TLS > > extension > > negotiation to add more items on the un-authenticated header, and > > potentially also remove redundant headers. > > I'd be interested in an analysis of the potential privacy > impacts of this. Isn't this more or less the same as doing > SPUD-for-DTLS? (If not, sorry for dragging in controversy:-) You can check the security considerations section of the latest draft: https://github.com/thomas-fossati/draft-tls-cid/blob/master/draft-mavrogiannopoulos-tls-cid.md TLDR; the privacy offered by this extension is the same as the privacy of DTLS over UDP. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] extending the un-authenticated DTLS header
Hi, For draft‐mavrogiannopoulos‐dtls‐cid‐00 and we needed to extend the DTLS un-authenticated part of the DTLS record header with an additional field. That works well if this is the only draft ever extending the DTLS record header. If not, modification order would be undefined. Would it make sense to introduce an extension header for DTLS 1.3 in the lines of the IPv6 extension headers? That would allow TLS extension negotiation to add more items on the un-authenticated header, and potentially also remove redundant headers. What do you think? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt
On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote: > Regarding Niko, my understanding is that the WG preferred not to have > the definition of profiles in this document. I am not sure you wanted > the text to be removed as MUST NOT was to normative or if you would > like no recommendation at all. The reason I would rather advocate for > recommendation is that ECDHE does not specify an algorithm with a > specific security. As a result, I would rather provide some guide > lines to avoid weak authentication being used with high long AES > keys. That's a valid concern, but TLS doesn't have the notion of a security level, and I am not sure that you can easily introduce it with a ciphersuite point assignment rfc. With TLS you can easily use AES-256 with DHE-RSA with DH parameters of 4096-bits, signed with an RSA certificate of 32-bits. One can use your draft with a 8-bit PSK, and still be insecure despite the fact that you force a 256-bit curve or better. When trying to ensure a consistent level you may likely need to adjust the finished message size as well. Nevertheless, I think to cover your goal, a security considerations addition that makes apparent that in addition to the ciphersuite parameters, the TLS protocol finished message size, the elliptic curves used, and the size of the selected key define the security level of the session. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt
On Mon, 2016-11-07 at 22:09 -0500, Daniel Migault wrote: > Hi, > > Please find the text I propose. Let me know if you have any comment > regarding the proposed text. Unless I receive comment on it, the text > will be publish as soon as draft submission is possible. > > Yours, > Daniel > > The cipher suites defined in this document are based on the AES- > GCM > and AES-CCM Authenticated Encryption with Associated Data (AEAD) > algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM, > and > AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and > AEAD_AES_256_CCM_8 defined in [RFC6655]. > > For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF) > with SHA-256 as the hash function SHALL be used and Clients and > Servers MUST NOT negotiate curves of less than 255 bits. Sorry for not getting back into previous discussions. My comment as before would be to remove the text "Clients and Servers MUST NOT negotiate curves of less than 255 bits." I find that unrelated to the purpose of the text which is define code points for certain ciphersuites, and no other code points for TLS set such restrictions (DH bits, or curves). Alternatively if with this document you want to create a profile of TLS (e.g, like SuiteB rfc does), which sets options which are more than just ciphersuites then just be clear about it. That is, say this document creates a profile of TLS named XXX which if used, the clients and servers which conform to it must negotiate the ciphersuites defined above and must not negotiate curves of less than 255 bits. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] debugging tools [was: Industry Concerns about TLS 1.3]
On Fri, 2016-09-23 at 09:05 +0100, Stephen Farrell wrote: > > On 22/09/16 19:36, Yuhong Bao wrote: > > > > This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?i > > d=1188657 > > Yuk. Prioritising the needs of those debugging networks > over the maybe 5-6 orders of magnitude more folks using > them is ass-backwards IMO. That result looks to me like > a very bad decision if I'm following it correctly. That's a very different concern than the one asked by BITS security, and is IMO a very valid one. Running any protocol under TLS wouldn't mean that debugging is very hard or impossible for the one running the protocol. Administrators debug and trace protocols every day to figure out failures (that's why we have advanced tools like wireshark). Making it hard for them to use these tools isn't increasing security; it is only making their life harder. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] application-specific identifier was: TLS1.3 + PSK with multiple identities
On Mon, 2016-09-19 at 14:13 -0700, Eric Rescorla wrote: > > > It is purely a matter of software architecture — the initial > > incoming > > UDP packets reach a dispatcher that needs to hand the connection > > off to > > the appropriate worker process for that client and *really* > > wants > > to make that decision based on the ClientHello alone. > > > > If we *start* the handshake in the main dispatcher and get to the > > point > > of seeing the ClientKeyExchange, we have to hand over the > > partially- > > completed handshake (or keep going and then hand over a fully- > > completed > > handshake) to the appropriate worker. And in fact I don't even > > think > > the dispatcher *has* the actual keys; only the identities so that > > it > > knows where to dispatch connections to. > > See above. The key advantage of what I am proposing here is that it > has > exactly the same cryptographic properties as current TLS-PSK, with > the > indicator just serving as a routing-ID. We've decided to take that approach. What we have currently is described at: https://tools.ietf.org/html/draft-mavrogiannopoulos-app-id-00 Comments are welcome. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SHA-3 in SignatureScheme
On Fri, 2016-09-02 at 10:04 -0700, Eric Rescorla wrote: > > > I also am not following why we need to do this now. The reason we > > defined SHA-2 in > > > a new RFC was because (a) SHA-1 was looking weak and (b) we had > > to make significant > > > changes to TLS to allow the use of SHA-2. This does not seem to > > be that case. > > > > I don't think we strictly _need_ to do this now, however I think > > it's a good idea given that we'll need to do it eventually > > I'm not sure that that's true. It is unclear to me what is the intention. Due to the semantics of the signatureAlgorithms extension in TLS 1.3, if the TLS 1.3 draft doesn't define SHA3, it effectively _bans_ the usage of SHA3 in all certificate chains intended to be used by TLS 1.3. If that's the intention then yes, SHA3 should not be included. In that case implementations of TLS 1.3 will have to wait for a SHA3 RFC to be published in order to enable the algorithm. That would introduce a delay, and in certain occasions (e.g., firmware) we will have TLS 1.3 implementations which may never support SHA3. IMO, unless there are doubts about SHA3's adoption as a certificate algorithm, it should be part of the TLS 1.3 spec. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 -> TLS 2.0?
On Tue, 2016-08-30 at 14:19 -0400, Dave Garrett wrote: > I occasionally see people ask why we're calling it TLS 1.3 when so > much has changed, and I used to simply think that it was too > bikesheddy to bother changing at this point. However, now that we've > redone negotiation, we have new TLS 1.3+ only cipher suites. The old > are not compatible with the new (new codepoints needed for old > ciphers) and the new are not backwards compatible with the old > (they'll just be ignored). We actually risk misconfiguration in the > future if the distinction isn't made clear. I think it's time we just > renamed TLS 1.3 to TLS 2.0. There are major changes, so labeling it a > major version seems more appropriate. I agree with the proposal. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead
On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote: > All, > > We've received a request for early IANA assignments for the 6 cipher > suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh > e-psk-aead/. Please respond before August 23rd if you have concerns > about early code point assignment for these cipher suites. I have previously raised an issue [0] on these ciphersuites. The same requirement was noted also by Peter Dettman as something special in [1]. However, there has been no reaction from the authors (now in CC). regards, Nikos [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ [1]. https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA
On Mon, 2016-08-08 at 14:55 +0200, Martin Rex wrote: > > Please see the paper "Another Look at ``Provable Security''" from > > Neal > > Koblitz and Alfred Menezes. > > > > https://eprint.iacr.org/2004/152 > > > > Section 7: Conclusion > > > > "There is no need for the PSS or Katz-Wang versions of RSA; > > one might as well use just the basic ?hash and exponentiate? > > signature > > scheme (with a full-domain hash function)." > The advantages of the RSA-PSS signature scheme are limited to > situations > where the rightful owner of the private signing key is not supposed > to have access to the bits of the private key (i.e. key kept in > hardware). Is that limited, so limited today? Aren't we at a time where the majority of servers will use an HSM (either real hardware or virtualized)? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 + PSK with multiple identities
On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote:
> On Mon, Aug 08, 2016 at 10:17:40AM +0200, Nikos Mavrogiannopoulos
> wrote:
> >
> > Hello,
> > I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3
> > draft [0], and I noticed quite some deviations (IMO) from typical
> > TLS
> > protocol behavior. No rationale is given about them so I ask on
> > list.
> >
> > To summarize, the client sends a list of identitities and the
> > server
> > replies with an index indicating which identity is approved.
> >
> > 1. The server reply with an index is unique in TLS. It is not used
> > in
> > ciphersuite selection or in any other negotiation in TLS where the
> > client sends multiple options. Why not have the server reply with
> > the
> > selected username.
>
> More compact and makes the option where server sends some bad option
> more clear.
I'm not sure about being more clear. What I immediately notice is that
it requires the client to remember not only the values that it sent,
but also the indexes. I guess that's no big deal, but it is used
nowhere else in TLS.
> > 2. Why does the client send multiple identities? In TLS-SRP a
> > single
> > identity is sent, and the same in the existing TLS-PSK rfc. How is
> > this
> > envisioned to be used? A client sends: I'm probably one of Bob,
> > Nikos,
> > George, take a look on that list and tell me who I really am? In
> > that
> > case why not allow the server, to reply with a username outside
> > that
> > list (i.e., assign a new one to be used at the next session - see
> > point
> > 1).
> You already need multiple if you try to "resume"[1] DHE-PSK session
> (since "resumption" shares the PSK space).
That's very awkward. That way the protocol mandates code like:
if (!id_in_resumption_db()) {
if (!valid_ticket())
if (!try_find_user_in_psk_userfile())
proceed_with_random_psk(); /* hide the fact that username
doesn't exist in db */
}
which is not really sane code. Not only that, but servers who would
like to prevent valid username testing in their PSK key file as above,
would be forced to make resumption attempts with unknown or long-
expired tickets fail.
A protocol must have clarity on the data sent on the wire and their
purpose. Cross protocol attacks work by exploiting data which may be
interpreted in multiple ways and such generic purpose identifiers seem
to be like a good candidate for that.
I think at minimum identities known to the protocol (e.g., resumption)
should be distinguishable from PSK usernames. The draft leaves that to
the server implementor to do, but I do think such identifiers should be
tagged at the protocol level since it affects all implementations.
> 3. The maximum size of the username is 2^16. Isn't that excessive
> > for a
> > user name or a user identifier? Why not set 2^8? That would fit a
> > uuid
> > or anything similarly large.
> If one wants to do the equivalent of tickets in TLS 1.2, one needs
> pretty large usernames.
I find that, as another unfortunate side-effect of combining unrelated
protocol fields.
regards,
Nikos
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS1.3 + PSK with multiple identities
Hello, I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3 draft [0], and I noticed quite some deviations (IMO) from typical TLS protocol behavior. No rationale is given about them so I ask on list. To summarize, the client sends a list of identitities and the server replies with an index indicating which identity is approved. 1. The server reply with an index is unique in TLS. It is not used in ciphersuite selection or in any other negotiation in TLS where the client sends multiple options. Why not have the server reply with the selected username. 2. Why does the client send multiple identities? In TLS-SRP a single identity is sent, and the same in the existing TLS-PSK rfc. How is this envisioned to be used? A client sends: I'm probably one of Bob, Nikos, George, take a look on that list and tell me who I really am? In that case why not allow the server, to reply with a username outside that list (i.e., assign a new one to be used at the next session - see point 1). 3. The maximum size of the username is 2^16. Isn't that excessive for a user name or a user identifier? Why not set 2^8? That would fit a uuid or anything similarly large. regards, Nikos [0]. https://tlswg.github.io/tls13-spec/#rfc.section.4.2.5 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3
On Fri, 2016-07-08 at 09:29 +, Fossati, Thomas (Nokia - GB) wrote: > > > > How would the hash chain matching work for a server handling > > > > multiple > > > > clients? > > > Sorry, I'm not sure I understand the question. Are you asking > > > what > > > happens if there is an Id collision between two separate hash > > > chains? > > No, my question is much simpler. How would a server handling for > > example 2 clients, will figure to which chain a hash of H(x) > > belongs to? Will it have to iterate through all the chains (client > > states) and test for matching or there is something more clever > > than > > that? > Ah! The hash chain would be computed at the end of the handshake, so > all L > Ids can be put in a hash table that maps them to the same DTLS > context. > When a data record comes in, its Id can be used to look up the > context in > O(1). > Clearly the server needs to negotiate a sensible L if it doesn't want > to blow up. As long as both the client and the server are able to notify each other that they only support L=1 I'd be content with it. However, I'd prefer a simple solution and defer the hash chain negotiation for a separate extension, since we cannot foresee how and if such an extension will be used. As we saw with heartbleed any unused complexity is not necessary adding value. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3
On Fri, 2016-07-08 at 08:59 +, Fossati, Thomas (Nokia - GB) wrote: > > How would the hash chain matching work for a server handling > > multiple > > clients? > Sorry, I'm not sure I understand the question. Are you asking what > happens if there is an Id collision between two separate hash chains? No, my question is much simpler. How would a server handling for example 2 clients, will figure to which chain a hash of H(x) belongs to? Will it have to iterate through all the chains (client states) and test for matching or there is something more clever than that? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3
On Fri, 2016-07-08 at 08:34 +, Fossati, Thomas (Nokia - GB) wrote: > Hi Nikos, Stephen, > > It seems to me that both your views (high resistance to traceability > and > low resource investment on server side) can be accommodated in a > single scheme. > Going back to the hash chain proposal that Stephen did a few emails > ago on > this same thread. If: > 1. the length of the hash chain is the shortest between the lengths > each > peer proposes, and Hi, How would the hash chain matching work for a server handling multiple clients? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3
On Thu, 2016-07-07 at 10:37 +0100, Stephen Farrell wrote: > Hiya, > > Just on this one thing... > > On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote: > > > > does not make the situation any worse > > than we have today. > I don't accept that is the correct goal. That form of > argument is what lead to us standardising the HTTP > Forwarded header field, which IMO was a disimprovement. > (An argument I lost in the end in that case [1], but > 'twas close, and back in 2012 so might go the other > way today;-) > I would argue that the correct goal is to make things > better whenever possible, with that being especially > important for protocols like (D)TLS on which many > other things depend. > I do agree that any scheme developed would need to > meet the state management requirements of servers. > I'm not convinced those requirements call for a new > super-cookie though:-) I understand your point, I'm not fully convinced by that argumentation. I may be wrong of course, but I'll try to explain my point. Indeed putting privacy first should be a goal of TLS/DTLS, but to the extent it covers the protocol goals. What you propose is to make a stream anonymous, untrackable. However, that (anonymity or untrackability of the stream) was never a stated goal of TLS/DTLS. In fact TLS is by definition trackable over TCP and one can see in the clear the IPs of the two peers communicating. That doesn't change by switching to DTLS, except for unfortunate situations of routers losing state and client roaming, which current servers cannot easily cope with, and that's the problem I attempt to address. I think the principle of doing one simple thing and doing it well, applies to protocols as well. TLS and DTLS provide a layer of confidentiality and authenticity. Anonymity, untrackability can be provided by other protocols focused on that such as TOR. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3
On Tue, 2016-07-05 at 15:24 +0100, Stephen Farrell wrote: > it doesn't contribute nor affect the security in any way). > > > Does that id need to be static? If so, then it'd act as an > > > additional way to track a user roaming over different IP and > > > ports. That'd be a pity. If such an id is useful, maybe there's > > > a way to allow it to change as well, in a way predictable for > > > the server. > > Could be, but I don't have a use case for such > Hmm. I'd hope we can all share a use case of bring more > privacy-friendly where possible and of not introducing > changes that are privacy-unfriendly unless absolutely > unavoidable. Thank you, now I understand your concern. However, I would like to point that a static identifier does not make the situation any worse than we have today. DTLS over UDP (or any other layer) is not anonymous, and DTLS as a protocol it was never meant to be. Moreover, any method to have a dynamic identifier should be of complexity that would make such an approach reasonable for a server to calculate without state (the problem this identifier solves is that a server doesn't know to which client this session belongs on receipt of a packet, thus it would have to calculate any dynamic identifiers without any state). regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3
- Original Message - > On 04/07/16 20:54, Nikos Mavrogiannopoulos wrote: > > > > where id is sent by the server to the client either via an extension, or > > by simply assuming that the client will copy and keep the ID seen at the > > server packets (it doesn't really matter that this ID is unprotected as > > it doesn't contribute nor affect the security in any way). > > Does that id need to be static? If so, then it'd act as an > additional way to track a user roaming over different IP and > ports. That'd be a pity. If such an id is useful, maybe there's > a way to allow it to change as well, in a way predictable for > the server. Could be, but I don't have a use case for such a switch nor can think something obvious, what do you have in mind? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3
- Original Message - > On Mon, Jul 04, 2016 at 03:54:19PM -0400, Nikos Mavrogiannopoulos wrote: > > - Original Message - > > > Hi all, > > > > > > I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document > > > and you can find the result at > > > https://github.com/tlswg/tls13-spec/pull/512 > > > > > > I have worked on a prototype implementation of DTLS 1.3 and if someone > > > else has something working by the time of the Hackathon in Berlin please > > > let me know. > > > > May I recommend a more radical approach for DTLS? My experience with > > servers > > handling DTLS traffic from various clients is that the clients change IPs > > (while > > roaming) and incoming ports (due to firewall state timeout), making > > impossible > > for the server to map the encrypted incoming packets from unknown IP/port > > combinations > > to any particular handler (i.e., handling process/thread or logical > > handler). That > > is because an independently received DTLS record packet has no session > > identifying > > information. > > I think in DTLS 1.2, that was meant to be handled at lower layer (of course, > often there isn't such layer even when needed). I'm not sure that is discussed at DTLS 1.2 protocol at all. It is mostly ignored as a problem. In the most unreliable layers (including UDP), this cannot be handled at the lower layer without introducing another layer. > > For that I'd like to propose the DTLS record format to include at least a > > 3-byte identifier which will allow servers to recognize streams coming from > > unknown > > sources. That would be similar to the SPI field in the ESP packets. That > > is, > > a format similar to: > One can't change the headers in ClientHello/ServerHello and expect to remain > backwards compatible. Why would these headers need to change? The ClientHello will be sent under DTLS 1.0 and if the server see that the client supports the version with the new format, it will reply using the new fields. The protocol's design can cope with such changes. > And how would that identifier be assigned? 0 in ClientHello, then copy > whatever the server sends? If the procedure above is followed the client will copy whatever it sees from the server's hello packet. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3
- Original Message -
> Hi all,
>
> I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document
> and you can find the result at https://github.com/tlswg/tls13-spec/pull/512
>
> I have worked on a prototype implementation of DTLS 1.3 and if someone
> else has something working by the time of the Hackathon in Berlin please
> let me know.
May I recommend a more radical approach for DTLS? My experience with servers
handling DTLS traffic from various clients is that the clients change IPs (while
roaming) and incoming ports (due to firewall state timeout), making impossible
for the server to map the encrypted incoming packets from unknown IP/port
combinations
to any particular handler (i.e., handling process/thread or logical handler).
That
is because an independently received DTLS record packet has no session
identifying
information.
For that I'd like to propose the DTLS record format to include at least a
3-byte identifier which will allow servers to recognize streams coming from
unknown
sources. That would be similar to the SPI field in the ESP packets. That is,
a format similar to:
struct {
ContentType type;
ProtocolVersion record_version = { 3, 1 };/* TLS v1.x */
uint24 id;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
where id is sent by the server to the client either via an extension, or
by simply assuming that the client will copy and keep the ID seen at the
server packets (it doesn't really matter that this ID is unprotected as
it doesn't contribute nor affect the security in any way).
regards,
Nikos
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call for keys used in handshake and data messages
On Mon, 2016-06-13 at 12:00 -0700, Joseph Salowey wrote: > For background please see [1]. > > Please respond to this message indicating which of the following > options you prefer by Monday June, 20, 2016 > > 1. Use the same key for handshake and application traffic (as in the > current draft-13) > > or > > 2. Restore a public content type and different keys Unless participants are really expert on what is the issue is and how these proofs are constructed, I doubt that people in the TLS WG can resolve that in a way that provides assurance. There are good arguments presented in the thread by few cryptographers, but since this is mainly a low level crypto decision, why not ask the CFRG instead? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]
I'm actually surprised you mention the microsoft servers as being version negotiation tolerant. They were the most prominent examples of terminating the handshake if TLS 1.2 was offered to them (that was much time before TLS 1.2 was implemented in browsers). regards, Nikos - Original Message - > On 7 Jun 2016, at 8:33 PM, Hubert Kario wrote: > > On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: >> I’m not sure this helps. >> >> I’ve never installed a server that is version intolerant. TLS stacks >> from OpenSSL, Microsoft, > > are you sure about that Microsoft part? > > there is quite a long thread on the filezilla forums about TLS version > tolerance in IIS: > https://forum.filezilla-project.org/viewtopic.php?f=2&t=27898 That’s surprising. The last time I tested with an IIS servers it was Windows Server 2003 and 2008. They did not support TLS 1.2, so I wanted to check if they could tolerate a TLS 1.2 ClientHello. They did. Of course, they replied with TLS 1.0, but that was expected. It’s strange that this behavior would degrade for much newer versions of Windows that came out at a time where several browsers were already offering TLS 1.2. I wonder if it’s just the FTP or also IIS. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
On Fri, 2016-06-03 at 00:17 -0400, Dave Garrett wrote: > Allrighty then; time to dust off and rebase an old changeset I was > fiddling with last year on this topic: > https://github.com/davegarrett/tls13-spec/commit/058ff1518508b094b8c9 > f1bd4096be9393f20076 > (I cleaned up a bit when rebasing, but it probably needs some work; > was just a WIP branch, never a PR) > This was the result of prior discussions on-list about TLS version > intolerance. The gist of the proposal: > 1) Freeze all the various version number fields. > 2) Send a list of all supported versions in an extension. (version > IDs converted to 16-bit ints instead of 8-bit pairs) > 3) Use short (1 or 2 value, based on hello version) predefined lists > for hellos from old clients not sending the extension. > 4) Compare lists to find highest overlap, avoiding guesswork or > problems with noncontinuous lists. > 5) Forget the old mess of version intolerance existed. I had originally similar thoughts, but doesn't that introduce a 4th version negotiation mechanism? We already have the current version negotiation mechanism(1), the extension mechanism(2), the ciphersuite negotiation(3), and we are getting a new version negotiation mechanism based on extensions(4). Note that (1),(2) and (3) aren't getting away if we introduce (4). The code will stay in implementations for more than a decade. A simpler proposal is: Consider TLS 1.3 as a feature, and negotiate it using an empty extension. If the extension is present a server assumes TLS 1.3. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: > 2% is actually pretty good, but I agree that we're going to need > fallback. Please not. Lets let these fallbacks die. Not every client is a browser. TLS 1.3 must be a protocol which doesn't require hacks to operate. CBC was removed, lets do the same for insecure fallbacks. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT)
On Thu, 2016-05-05 at 12:39 -0400, Jeffrey Walton wrote: > On Thu, May 5, 2016 at 10:49 AM, Stephen Farrell > wrote: > > > > > > Thanks all. I updated the RFC editor note to add the FIPS > > reference. > > > You might also consider mentioning the interop problems that are > going > to occur when diverging from Bernstein's reference implementation. > Its > already creating open questions on other mailing lists. For example, > linux-crypto and > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1137554. > html: > > > + chacha20_block(&crng->state[0], out); > > + if (crng->state[12] == 0) > > + crng->state[13]++; > > state[12]++? Or why do you increment the nonce? I wondered the same when I saw the comment. However, I'm not sure that is an issue. Chacha20 as a stream cipher is not defined anywhere by IETF (as far as I know). RFC7539 defines Chacha20-poly1305 AEAD (authenticated encryption) mechanism which uses a modified chacha20 than the reference algorithm. However, that doesn't really affect any other uses for the stream cipher. That's maybe the reason for the confusion. Bottom line, the comment relates more to RFC7539 rather than this draft. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead
On Mon, 2016-04-25 at 08:17 -0700, Sean Turner wrote: > All, > > draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that > are needed for TLS1.3. We need to get these officially registered so > the chairs would like to hear whether there is WG support for > adopting draft-mattsson-tls-ecdhe-psk-aead. Please let us know > whether you: I support this draft. However see comment below. The text: "For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF) with SHA-256 as the hash function SHALL be used and Clients and Servers MUST NOT negotiate curves of less than 255 bits." is very tricky. Implementations do not restrict ciphersuites based on curves (there is no such notion in TLS, nor mentioned in rfc4492), and I cannot even think how a TLS handshake implementation would look like if each different ciphersuite has specific curve requirements. Note that this requirement is unlike the suiteB RFC (rfc6460) that also restricts the curves. SuiteB specifies a profile/set of parameters which include ciphersuites, while this draft only defines ciphersuite code points. If a side goal of this draft is to deprecate the <255 bit elliptic curves from TLS 1.2, or to unify security levels across ciphersuites then I'd recommend to do that with a separate RFC rather than bundling it into a code-point assignment RFC. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0
On Wed, 2016-03-16 at 12:36 +, Peter Gutmann wrote: > After a number of, uh, gentle reminders from people who have been > waiting for > this, I've finally got around to posting the TLS-LTS draft I > mentioned a while > back. It's now available as: > > > http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt I liked the idea of an LTS profile for TLS 1.2, however I just realized that RFC7540 [0] blacklists (with no rationale) 3 out of the 4 LTS ciphersuites and I'm wondering how practically useful will be that profile. regards, Nikos [0]. https://tools.ietf.org/html/rfc7540#appendix-A ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted)
On Sat, 2016-03-19 at 07:51 -0700, Watson Ladd wrote: > On Fri, Mar 18, 2016 at 4:31 PM, Peter Gutmann > wrote: > > > > Watson Ladd writes: > > > > > > > > Then use a padding extension that solves all problems, instead of > > > relying on > > > a side effect of CBC mode. > > It's not a "side-effect of CBC mode", CBC mode allows padding > > packets, GCM > > doesn't, see Colm MacCárthaigh's recent post on the topic. > GnuTLS is the only implementation that pads to more than 16 byte > boundaries This is no longer true. We disabled that feature few years ago since it was the main cause for several compatibility failures. The failures were with other broken implementations, but no-one cares who is at fault if the session doesn't work. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
On Sun, 2016-03-13 at 13:38 +0100, Eric Rescorla wrote: > > > > However, if I'm in the rough about the above, (which seems > > to me to be the case now) then my job as AD when I get a > > publication > > request that includes 0rtt, will include figuring out if that's > > safe or not. And I've no clue how I'll do that unless the WG > > have already done some analysis of the many, many protocols > > that use TLS. Note that I do not consider "use a different API" > > to be a sufficient answer here (it is necessary, but not > > sufficient). > It seem to me that there are several important mitigating factors > here. > > 1. Nothing requires applications to use this feature at all. First, > servers > need to advertise it and are free to (a) not offer clients the > ability to send > 0-RTT data and (b) refuse to accept it if clients send it. Moreover, > everyone > I know of who is considering building a 1.3 library intends to > provide > that data to the server via a separate API, so the server will have > to work > to get it. It is important to see how protocols are perceived. For many people TLS 1.3 with 0rtt will be the same as TLS 1.3. The first publication of an attack against TLS 1.3 with rtt, will be perceived as an attack against TLS 1.3 protocol. Even if the published attack against TLS 1.3 with 0rtt was an expected one (i.e., replay of data), if the attack impact is high, that may not be sufficient to stop the avalanche of bad publicity. In turn that will lead several people losing confidence to TLS 1.3 as a protocol, even TLS and the IETF process overall. My suggestion, if you need 0rtt, publish it as a different document, don't mix it with TLS 1.3. The security requirements from TLS are vastly different from the security requirements of a 0rtt protocol. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
On Fri, 2016-03-04 at 13:49 +, Scott Fluhrer (sfluhrer) wrote: > Given that there probably is no long term future for RSA anyway > > > (people want ECC and postquantum is ahead) I doubt anything else > > > than > > > the primitives we already have in standards will ever be viable. > > On the contrary. If we have a future with quantum computers > > available, the > > only thing that we have now and would work is RSA with larger keys, > > not ECC. > RSA isn't *that* much more secure against a Quantum Computer than > ECC. It would appear to take a larger Quantum Computer to break RSA > than it would to break ECC (for reasonable moduli/curve sizes), > however not that much more. It is possible that, at one stage, we'll > be able to build a QC that's just large enough to break EC curves, > but not larger RSA keys - however, we would be likely to be able to > scale up our QC to be a bit larger; possibly in a few months, quite > likely in a year or two. Hence, moving back to RSA would appear > likely to buy us only a short window... > > I agree with Hanno; if we're interested in defending against a > Quantum Computer, post Quantum algorithms are the way to go Assuming that we have such algorithms which are practical to manage and deploy we would first need to enhance existing protocols with them, including TLS and PKI. Then it is only the (simple) task of upgrading/replacing every single piece of infrastructure we have today from certificates to implementations with the new algorithms. Unless you can use the quantum computer to complete the above transition overnight, the quickest way to defend against the presence of a quantum computer is by allowing larger RSA keys. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
On Thu, 2016-03-03 at 17:11 +0100, Hanno Böck wrote: > It may be worth asking the authors what's their opinion of FDH vs > > PSS > > in view of the state of the art *today*. > You may do that, but I doubt that changes much. > > I think FDH really is not an option at all here. It may very well be > that there are better ways to do RSA-padding, but I don't think that > this is viable for TLS 1.3 (and I don't think FDH is better). > PSS has an RFC (3447) and has been thoroughly analyzed by research. I > think there has been far less analyzing effort towards FDH (or any > other construction) and it is not in any way specified in a standards > document. If one would want to use FDH or anything else one would > imho > first have to go through some standardization process (which could be > CFRG or NIST or someone else) and call for a thorough analysis of it > by the cryptographic community. Which would take at least a couple of > years. > > Given that there probably is no long term future for RSA anyway > (people > want ECC and postquantum is ahead) I doubt anything else than the > primitives we already have in standards will ever be viable. On the contrary. If we have a future with quantum computers available, the only thing that we have now and would work is RSA with larger keys, not ECC. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
